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ABSTRACT.: 

The  differences  between  sequential  and 
concurrent  programs  are  identified.  These 
differences  dictate  how  the  design  of  a  debugger 
for  concurrent  programs  must  differ  from  a 
sequential  debugger.  Different  techniques  to 
facilitate  debugging  of  concurrent  programs  are 
discussed.  The  implementation  of  a  tracing 
facility  for  Concurrent  C  programs  is  presented. 
This  implementation  enables  all  of  the  processes 
in  a  Concurrent  C  program  to  be  presented  by  icons 
on  a  CRT  which  keeps  tracK  of  their  individual 
process  state.  Furthermore!  trie  ability  to 
breakpoint  a  process  and  at  the  same  time  suspend 
all  the  other  existing  processes  within  a 
Concurrent  C  program  is  implemented  in  this 
f  a  c  i  I  i  t  y  . 
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Chapter  1 
Introduction 


Generally!  a  computer  program  is  developed 
tnrough  a  sequence  of  steps.  These  steps  can  be 
divided  intu  (our  phases  namely: 


1)  un oer stand i ng  the  problem» 

d)  uesigning  a  solution! 

3)  implementing  the  solution  and 

i)  testing  tn  e  solution. 


The  first  phase  is  concerned  with  the 
specification  lobjective)  of  a  solution. 
Understanding  a  proolem  is  accomplished  by 
studying  the  docurr.entat  i  on  surrounding  the  problem 
in  detail  so  that  a  programmer  can  comprehend 
tnoroughly  what  is  to  oe  solved.  The  design  phase 
is  concerned  with  how  the  specification  can  be 
achieved.  This  is  normally  done  by  laying  out  the 
logical  flow  or  general  structure  of  a  program. 
Furthermore!  it  may  involve  selection  of  data 
structures  to  make  the  program  more  efficient  so 
that  the  program  executes  faster  or  requires 
minimal  iremcry  space.  Tne  implementation  phase 
deals  with  tne  conversion  of  the  designi  derived 
during  the  second  phase  into  real  programs.  This 
third   phase  involves  coding  and  compilation.   The 


testing  phase  is  usea  to  ensure  that  the 
spec i t i ca t i on  is  accomplishes.  This  involves  the 
execution,  verification  ana  debugging  of  a 
comp  i  I  ea  proq  ram. 

The  debugging  process  dLring  the  testing 
phase  of  a  program  development  is  the  focus  of 
this  thesis.  In  fact,  this  thesis  presents  ways 
to  make  a  programming  environment  conducive  for 
concurrert  programming. 

In  order  to  focus  on  debugging,  one  needs  to 
understand  sose  cf  the  terminology  associated  with 
debugging.  When  a  program  is  said  to  contain  a 
bug,  then  that  program  has  an  error.  Debugging 
is  the  process  of  locating  the  cause(s)  of  an 
error  and  fixing  the  error(s).  Debugging  is 
necessary  wnen  the  cause  of  errors  is  not  apparent 
to  a  programmer.  But  how  does  one  know  that  there 
is  an  error  in  the  program?  Errors  are  discovered 
when  the  behavior  of  a  program  does  not  conform  to 
its  specification  (assuming  the  specification  is 
correct). 


In  order  to  study  the  behavior  of  a   program, 
test  data  are  needed.   with  a  'proper'  formulation 
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of  test  datdi  all  of  the  desired  behavior  of  a 
program  can  be  reviewed.  Unfortunately,  the 
formulation  of  'proper'  test  data  which  reveals 
all  of  the  behavior  patterns  or  a  program  is  very 
difficult  to  accomplish  when  the  program  is 
comp lex. 


Concurrent  programs  are  always  more  complex 
to  debug  than  sequential  programs.  This  is 
because  the  behavior  of  a  sequential  program  is 
independent  of  time  whereas  a  concurrent  program's 
behavior  can  be  time  dependent.  A  concurrent 
program  is  composed  of  two  or  mere  seauential 
programs  that  may  execute  concurrently  as  parallel 
processes.  During  their  execution,  these 
processes  may  occasionally  interact  witn  each 
other.  The  act  of  occasional  interaction  via 
synchronization  and  cooperation  is  called 
asynchr on i sm .  The  processes  involved  in  this 
interaction  are  called  asynchronous  processes.  A 
classical  example  of  asynchronous  processes 
involves  producer  and  consumer  processes  where  a 
producer  produces  as  fast  as  possible  until  it  has 
to  wait  for  the  consumer  to  catch  up  with  it  or 
vice  versa. 


An  exairple  of  a   time   dependent   program  is 

illustrateu   belowt    Let   x   ana   y   Be   tne  two 

processes  which  share  a  common  variable!   s.  The 

pseudo   Concurrent  C  [GEHANI  £  ROOME  84a]  code  for 
tne  two  processes  is  shown  in  Figure  1.0. 


Process  x : 
{  local  variables 
XI  t  X2  ; 

XI  «  si 

x2  =  xi  +  10 ; 

s  =  X2; 


Process  y  '• 
C  local  variables 
Yl,  Y2 ; 

y  i  =  s ; 

Y2  =  Yl  +  20; 
s   =  Y2! 


Figure  1.0:  An  example  of  time  dependent  program 
in  pseudo  Concurrent  C 


Assume  that  the  initial  value  of  s  is  1  and 
that  this  vari2Dle  is  shared  by  both  processes. 
Alsoi  assume  that  both  processes  start  at  the 
same  time.  Nowi  consider  that  process  y 
executes  faster  tnan  process  x»  i.e.*  y  has 
executed  s  =  Y2  before  x  executes  XI  ■  s.  In  this 
scenario!  XI  gets  the  value  of  21  and  X2  is  set 
equal  to  31.  Cn  the  otner  hand!  suppose  process 
x  executes  faster  than  process  yi  i.e.!  x  has 
completely  executed  before  y  is  started.  In  this 
case!  XI  gets  the  value  of  1  and  X2  gets  11. 
Thus  the  values  of  Xl  and  X2  are  different  in  both 
scenarios  because  of  the   speed   of   execution   of 


-  5  - 
each   process.    This   phenomenon   is  called  'race 
con  a  i  t  i  en  •  ' 

Another  possibility  of  'race  conaition1  is 
the  interleaved  execution  aue  to  the  lack  of 
atomicity  (see  hi  cure  1.1).  In  this  c  a  s  e  i  the 
initial  value  of  x  is  50.  But  the  value  of  x  in 
process  1  can  oe  <tC  or  20  depending  how  the 
assignment  statements  are  executed.  The  value  of 
x  in  process  1  can  oe  <iCi  if  the  assignment 
statement  is  executed  first*  without  interleaving 
with  process  2's  assignment  statement. 

x  =  50; 

Process  1:  Process  2: 

x  »  X  —  XOi  x=x-20i 

Figure  l.l:  An  example  of  interleaved  execution 
due  to  the  lack  of  atomicity 

The  major  difference  between  concurrent  and 
sequential  urograms  involves  synchronization. 
Synchronization  is  the  constraint  imposed  on 
autonomous  processes  within  a  concurrent  program 
to  coordinate  them  and  to  keep  them  from 
interfering  with  each  other.  This  is  often  called 
the  timing  constraint  [ANDREW  £.  SCHNEIDER  83). 
[DEITEL  8<i]  . 


With  an  unuer stano ing  of  the   terminology   of 
debugging   ana  concurrent  programming.   the  reader 
may  now  proceed  to  tne  gist  of  the  paper.   To   aid 
tne   reader,    here   is   how  the  remainder  of  this 
thesis  nas   been   organized.    In   chapter   2>    a 
historical    survey   of   debuggers   is   presented. 
Also,   four  existing  debuggers   are   presented   in 
order  to  show  different  features  that  are  commonly 
found  in  debuggers.   Chapter  3  covers   "low-level" 
debugging    incluaing   a   discussion   of   hardware 
supports   for   debugging.    Chapters   4    presents 
current    techniques    from    different   areas   in 
computer  science  that  might  be  incorporated  into  a 
debugger.    In   particular,   applicable  techniques 
from   databases   and   techniques   associated   with 
artificial   intelligence  are  covered  in  chapter  4. 
Chapter  5  deals  with  the  difficulties  of  debugging 
a   concurrent   program,    and   includes   ideas  and 
approaches  for  concurrent  program  debugging.    The 
last   chapter,    comments   on   future   research  In 
debugging  especially  for  concurrent  programming. 


Cnap  ter  1 
History  and  survey  or  debuggers 


Nornally>  when  you  talk  about  a  subject)  it 
would  be  ideal  to  cover  the  history  of  that 
subject.  History  is  a  useful  tool  in  helping  to 
diagnose  wnat  has  gone  wrong  and  try  to  teach  us 
how  to  avoid  the  same  pitfall  again)  and  possibly 
providing  a  solution  wher  a  researcher  follows  the 
same  path  as  a  prior  one.  This  diagnosis  may  also 
stimulate  different  avenues  of  approaching  how  to 
solve  similar  problems.  As  a  result)  this 
chapter  starts  off  with  an  account  of  the  history 
of  oeDuggers  and  then  a  survey  of  four  existing 
deb  ug  ge  r  s  . 

2)1;   HiSifiLY  2i  asai(35SIi 

In  the  lino's  and  19s0's»  debuggers  were 
nonexistent.  This  was  partly  due  to  the  lack  of 
hardware  ana  software  technology.  Furthermore) 
computers  were  net  used  on  a  large  scale  a rd  those 
who  used  their  were  either  professicnals  or 
researchers.  At  that  time>  an  assembly  language 
was    considered    an    easy     language    to    use    as    compared 
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to  flip-flop  switches.  It  was  only  in  the  middle 
195C's  that  high  level  larguages  were  invented. 
With  the  understanuing  of  constructing  a  compiler 
and  wore  demand  for  'user  friendly'  programming 
environments,  debuggers  started  to  emerge  in  the 
early  lS60's  and  Doomed  in  the  1970's.  Initially, 
storage  dump  and  output  traces  were  the  only  ways 
to  help  in  debugging  a  program.  with  better 
developec  hardware,  hardware  interrupts  were 
possible  which  permitted  stepping  through  a 
program.  From  single-step  breaKpointing,  a  more 
sophisticated  approach  was  incorporated  and 
resulted  in  conditional  br eakpo i nt i ng . 
Conditional  br eak po i n t i ng  is  a  facility  in  which  a 
breakpoint  will  be  triggered  if  the  associated 
conditionls)  is  met.  In  order  to  provide  an 
interactive  debugger  with  user  friendl  iness,  the 
symbolic  debugger  were  developed.  A  symbolic 
debugger  is  capable  of  interpreting  the  symbols 
employed  Dy  a  user  in  his/her  program  during  a 
debugging  session,  whenever  a  reference  to  a 
storage  location  is  desired.  Further  explanation 
of  symbolic  debugger  will  be  provided  in  the  next 
section. 


In  the  1970*s,   almost  all  of   the   debuggers 


for  a  language  were  developed  after  the 
program. Ting  language  itself  and  this  created  some 
ad  noc  ways  of  i  mp  I  erne  nt  ing  a  debugger.  Moreover? 
all  those  debuggers  were  for  sequential  programs 
only.  In  fact)  more  recent  debuggers  which  were 
developed  in  parallel  with  a  language  are  more 
powerful  than  their  counterparts  which  were 
developed    after    a  language     was     already 

implemented.  This  power  is  due  to  features  like: 
switcning  a  nebugging  session  to  another  terminal 
(to  save  important  debugging  information)  as  when 
the  terminal  is  limited  to  a  certain  buffer  size)» 
scoping  of  debugging  commands  (to  elirrirate 
lengthy  commands*  anc  express  commands 
unambiguously  if  variable  names  are  duplicated  in 
multiple  pr oce cur es/ f un ct i ons ) »  and  adopting  the 
same  language  constructs  for  debugging  commands 
that  are  present  in  the  associated  high  level 
language  (to  eliminate  learning  a  new  set  of 
syntax).  Furthermore)  if  a  system  is  designed 
w i tn  the  consideration  of  incorporating  a 
debugger*  then  tnat  debugger  is  more  powerful 
because  special  features  to  facilitate  the 
debugger  have  already  been  incorporated  into  the 
system. 
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Only  in  tne  late  1970's  aia  debuggers  for 
concurrent  programs  start  to  exist.  This  is 
partly  due  to  the  lack  of  hardware  support  before 
and  partly  because  there  was  not  much  demand  for 
concurrent  programming  with  high-level  languages. 

Currently)  there  are  many  debuggers  (both 
sequential  and  concurrent)  tailored  for  specific 
systems)  but  most  of  them  are  not  designed  with 
po  r  tab  i  I  i  t  y  in  [find. 


2.2:  Symbolic  Qebygae£ 

A  symbolic  debugger  is  one  which  can 
understano  symbols  employed  by  a  user  in  his/her 
program  during  a  debugging  session  instead  of 
storage  addresses.  These  symbols  can  be 
variables)  constants)  procedure  or  function 
names)  etc.)  whicn  are  declared  within  a  program 
itself.  In  oroer  for  the  debugger  to  understand 
all  those  symbols)  a  symbol  table  is  required  in 
order  to  interpret  them.  Normally)  this  table 
consists  of  the  attributes  of  each  symbol. 
Attributes  like  type  of  declaration)  addressing) 
value)  range  of  values)  upper  and  lower  bcunds 
of  array  subscripts  are  ustally  kept  in  the  table. 
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Furthermore)  a  symbol  Ud  Ic  is  generated  during  a 
compilation     if     it     is    requested    Dy    the       user.  The 

table's  generation  is  optional  since  the  symbol 
table  could  be  very  large  depenaing  on  the  size  of 
the  program  and  is  useless  if  debugging  is  not 
needed  . 

2.3:   Sy£Y.£y.  a!  Fayr.  QsUyaaati 

The  four  debuggers  to  be  discussed  are  UNIX's 

adb   anj  dbx,    Tandem  Nonstop  II's  INSPECT  and  a 

PASCAL32  debugger.  The  reasons  for  choosing  these 
are: 


1)  they  reside  in  different  environments  and* 

2)  they  exhibit  different  features?   especially 
from  the  aspect  of  user-friendl  iness. 

A  comparison  table  for  the  four  debuggers  is  shown 

in  Figure  2.0.   Tne  features  chosen  for  comparison 

are   partly   based   on   criteria   for   interactive 

debugging   suggested  by  Seidner  [SEIDNEk  £  TINDALL 

831  . 
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[Debugger                1  ado  1  dbx  1  INSPECT  !  PASCAL/32! 

[User  friencliness      !      !   X   !    X      !     X      i 

1  Eas  y  to  use            !      !X!    X      1     X      ! 

{Descriptive  Operators!      !   X   !    X      !     X      ! 

[Source  level  debugging!      !   X   !          !           • 

[Symbol ic  debugging     !   X   !   X   !    X      1     X      ! 

[Interactive  debugging  1   X   [   X   1    X      !     X      i 

[On-line  help          1      !X!    x      !           1 

[Low-level  debugging    !   X   1   X   ]    X      1     X      ! 

[ASCII  display           1       [   X   !     X      IX       ! 

[Teririnalin  dependent   !      !      !    X      !           t 

[Concurrent  Prograrr     1      !      !    X      !     X      i 
IDeDugg  i  ng              III          1           1 

Figure   2.0:    Comparison    table    of    trie    four    debuggers 


2.3.1:    £db. 


ado  [TUTHILL  65b]  was  the  first  general 
purpose  debugger  on  UNIX  system.  It  is  not  user 
friendly  at  3ll  and  the  fundamentals  of  its  usage 
are  quite  haru  to  grasp.  As  usuali  the 
accompanying  documentation  for  these  UNIX  system 
programs  are  very  brief  and  quite  difficult  to 
comprehend  if  user  is  not  famil  iar  with  the  system 
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[UNIX  831.  Tne  syntax  ot  trie  debugger  is  quite 
foreign  to  UNIX's  host  language,  C,  and  other 
high-level  languages  like  PASCAL,  FORTRAN,  LISP, 
etc.  The  syntax  is  closer  to  an  assembly  language 
with  weird  symbols  like  '.',  '*',  '  il '  ,  '?', 
etc.  But  it  allows  user  to  set  breakpoints, 
define  action  to  be  taken  when  the  breakpoint  is 
reached,  display  tne  content  of  memory,  display 
the  stack  which  keeps  track  of  call  sequences, 
etc.  Programs  can  be  debugged  without  the 
insertion  of  any  user  interface  routine  in  the 
program . 


adb  provides  a  controlled  environment  for 
debugging.  When  a  program  needs  to  be  debugged, 
it  must  be  compiled  and  the  object  file  produced 
must  then  be  submitted  to  a ub .  SymDolic  debugging 
is  available  only  if  a  program  was  compiled  with 
symDol  table  option  ircludec.  An  analysis  of  a 
crashed  program  can  be  performed  when  a  core  image 
of  that  crashed  program  is  avai  lable.  Aab  enables 
a  user  to  display  the  contents  of  physical 
registers  in  a  manner  reminiscent  of  a  memory  dump 
in  an  IBM  environment.  For  details  about  'adb', 
refer  to  AOBll)  of  UNIX  Programmer's  Manual 
[TUTHILL   85bl  .    NOTE:    novices    are    strongly 
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advised      NOT       to       use       ado       at       all    because    it    can 
become    frustrating    very    guicKly.  Novices       should 

use    the    nsxt    debugger!       CDx     instead. 

2.3.2:    flfcx. 

ubx  is  a  debugger  capaole  of  debugging  a 
program  at  the  source  level  under  UNIX  operating 
system.  Currently!  it  supports  Fortran  77  and  C 
programs.  It.  is  a  symbolic  debugger.  Qbx  is  also 
a  source  level  debugger!  which  means  that 
interaction  with  source  text  during  debugging  is 
possible.  ror  irstancei  displaying  source  text» 
during  debugging  to  see  which  line  the  program  has 
just  executed  and  which  line  is  to  oe  executed 
next  is  permitted.  This  kind  of  tecnnique  is  a 
step  towards  instituting  a  "paperless  programming" 
environment.  For  a  truly  "paperless  programming" 
env  i  romrent ,  a  multiple  screens  capability  is 
essential  on  a  terminal  ICiU)  to  permit  different 
portions  of  a  program  to  be  displayed  at  the  same 
time  on  the  CRT  screen.  This  feature  would 
eliminate  the  snuffling  of  a  program  listing. 

obx  uses  English  verbs  like  'run1!    'trace'! 
etc.!    to  name  and  introduce  its  functions.   with 
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this  me i hod  of  naming!  a  user  can  recall  a 
function  easily*  Tracing  of  statements* 
variables  and  procedures  or  functions  are  possible 
and  optional  predicates  associated  with  them. 
Br eak po in t i ng  at  statement)  variable  and 
procedure/function  levels  are  also  available.  The 
reporting  of  all  trace  and  breakpoints  that  are 
set  in  a  program  can  be  invoked.  Of  course, 
modifying  and  displaying  of  any  symbol's  value  is 
allowed  ana  an  inquiry  can  be  made  about  the 
attribute  of  any  symbol. 

If  a  user  has  the  desire  to  debug  the  program 
at  machine  instruction  level,  he/she  is  permitted 
to  oo  so.  User  friendly  commands  like  on-line 
help  for  a  synopsis  of  dbx  command  and  'aliasing' 
for  shortening  command  expression  are  also  at 
user's  disposal.  The  major  difference  between  dbx 
and  aob  is  that  dbx  has  a  higher  level  user 
interface  tnan  adb  ITUThlLL  85a].  For  more  detail 
aDout  dbx.  refer  to  1>3X(1>  of  UNIX  Programmer's 
"lanua  I  . 

2.3.3:  Isaflsa  Naosisc  II  Qsbvaasi'  1NS£££I 

The  symbol ic  debugger  of   Tandem   Nonstop   II 


-  16  - 

computer  system,  'INSPECT*  enables  a  user  to 
initiate  a  ueDugqmy  session  at  a  terminal  and 
then  routes  the  input  or  output  of  that  deougging 
session  to  a  different  terminal  on  the  same  or 
cifferent  Tandem  system(s).  This  capability  is 
accomplished  by  the  concept  of  a  program  running 
as  a  process  and  'INSPECT'  running  as  a  process 
also.  INSPECT  is  as  user  friendly  as  dbx  except 
that  it  does  not  allow  source  text  to  be  displayed 
during  the  deDugying  session.  However,  it  has 
other  good  features  like  FILES  (which  displays  the 
status  of  opened  files  within  the  program),  TERM 
(which  can  be  used  to  switch  INSPECT  session  to 
different  terminal),  HIGH  and  LOW  (switches 
INSPECT  between  nigh-level  programming  language 
and  assemoly  language  mode),  RADIX  (sets  the  base 
for  numeric  conversion),  SCCPE  (sets  the  scope 
for  subsequent  commands  i.e.,  allow  a  query  about 
the  value  of  variables  outsiae  the  current  scope 
of  a  section  of  code)  and  COMMENT  (adds  comments 
to  tne  log  file  or  to  command  files).  As  it  is  a 
symbolic  debugger,  a  symbol  table  is  generated 
during  compilation  whenever  the  '?SYMB0L' 
directive  is  included  in  tne  source  code.  For 
more  detail  about  'INSPECT',  refer  to  INSPECT 
Interactive  Symbolic  Deougger  User's  Guide  [TANDEM 
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83]. 

2  .  3  .  A:   PAS.C.AL./32 

PASCAL/32  is  a  symbolic  debugger  for 
sequential  ana  Concurrent  Pascal.  It  has  almost 
the  same  capabil  ities  as  dbx  and  INSPECT  except 
for  a  few  features  which  are  unique  to  dbx  or 
INSPECTS.  Nevertheless!  it  has  features  for 
debugging  concurrent  programs.  "SUMMARIZE"  is  a 
command  which  produces  a  summary  I  ist  of  the 
status  of  all  active  processes.  The  summary 
consists  process  PCB  address)  the  current  process 
statei  the  current  program  counter.  global  basei 
etc.  Another  concurrent  program  debugging  command 
is  "TRACEBACK"  which  proviaes  a  tracebach  listing 
all  of  the  active  processes  starting  from  the  main 
process  (whicn  initiateu  all  of  its  child 
processes ) . 

2.3.5:  i^ii^ii  0.1  1Q2  tauL    iS.tLU22B.LZ 

As  time  elapses.  depuggers  are  becoming  more 
user-friendly  as  proved  by  the  evolution  from  adb 
to  dbx.  This  is  so  because  user -f r i end  I  i ne ss  is 
demanded  in  all  software.  and  more  advanced 
technology    is    available    now    than    before. 
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Fur  therrror  e ,  aeuugqers  seem  to  be  easier  to  use 
and  a  "paperless  programming"  approach  las  evident 
by  source  level  debugging)  can  be  adopted. 
However)  each  debugger  has  its  own  salient 
features.  These  features  are  system  dependent. 
Qn  the  whole.  debuggers  are  thdught  to  be  a  piece 
of  software  which  facilitates  a  user  in  debugging 
a  program.  Thus.  all  debuggers  are  built  with 
the  intention  to  nelp  a  user  as  much  as  possible 
in    debugging    his/her    program. 

2.4:      Fu.iu.is.    f2£b,uidS£rs 


Besides  symbolic         debuggers         using  the 

operating  system  capabilities  of  the  environment) 
debuggers  are  beginning  to  make  usage  of  different 
tools  in  recent  years.  Tools  such  as  databases) 
multiple-window         software/hardware*  graphical 

har dwar e/ sof twar e  and  knowledge-bases  or  Al  have 
been       incorporated       into      debuggers.  With         the 

incorporation  of  databases  and  know  I edg e-bases ) 
back-tracking  and  English  sentences  for  queries 
during  debugging  are  now  often  possible.  On  the 
other  hand)  multiple-window  layouts  and  graphical 
features  enable  programmers  to  debug  their 
programs    with    little    or    no      hard-copy.         With      all 
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these   new  ideas*   future  debuggers  should  Be  very 
easy  to  use. 


Unfortunately*  little  work  has  been  Cone  on 
debug ging  concurrent  program,  ^iill  the  knowleage 
of  debuggers  for  sequential  programs  help  in  the 
construction  of  an  adequate  debugger  for 
concurrent  programs?  This  problem  is  addressed  in 
the  subsequent  chapters. 
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Chapter  3 
Low-level  debugging 


"Low-level"  debuaging  is  concerred  w  i  tn 
memory  dumps  ano  the  interactive  examination  of 
memory  [HAMLET  B3J.  At  this  level,  a  user  is 
often  overwhelmed  with  data  ano  must  be  able  to 
extract  the  pertinent  data  to  fulfill  his/her 
requirement*  otherwise  the  data  are  useless.  The 
difference  Detween  "low-level"  and  "high-level" 
debugging  is  the  ease  witn  which  relevant  data  can 
be  extracted  by  the  user.  For  instance?  in 
"low-level"  debugging  the  user  has  to  know  the 
relative  position  of  a  variable  declared  in  a 
program  in  order  to  locate  its  content  from  the 
associated  memory  dump  of  data  segment.  Un  the 
other  hand,  in  "n  i  gh- 1  e  ve  I  "  debugging  all  the 
user  has  to  do  is  to  specify  which  variable  is  to 
have  its  value  oisolayed. 

3.1:  iSliaaLS  5u.DO.ciI 

Software  Support  is  concerned  with  software 
packages  avai  lable  to  users  which  can  faci  litate 
in    the    debugging    of     their    programs. 
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3.1.1:  Loa-isvej.  y.eoug.q.er. 

Both  the  memory  dump  ana  interactive 
examination  of  rueirory  rely  on  br  eak  po  in  t  i  ng. 
Breakpoint iny  is  the  temporary  halting  of  an 
executing  program.  Br edk po i n t i nq  is  usually 
accomplished  by  the  insertion  of  a  "pre ak po i n t" 
instruction,  »hicn  is  supported  by  the  hardware 
in  the  appropriate  segment  of  the  executable  code 
of  a  program. 

In  the  case  of  a  memory  dump,  the  breakpoint 
is  set  immediately  after  the  point  where  the 
program  needs  to  oe  diagnosed  and  the  state  of  the 
program  is  preserved  for  dumping.  At  that  time, 
the  program  is  also  terminated  anc  the  state  is 
printed  (dumped).  However,  in  the  case  of 
interactive  examination  of  memory,  conditional 
br eakpo i n t i ng  is  necessary  because  the  setting  of 
br  eakpo  in  t<  s  )  dynamically  by  a  user  during  the 
debugging  session  is  possible. 


The  approach  to  implementing  conditional 
breakpo in t i ng  is  hardware  dependent.  ail  of  the 
approaches  use  some  sort  of  exception  handling 
which     is     availaule     on     the     hardware. 
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Unfortunately)  breakpoints  are  extremely 

difficult  to  errceu  in  code  produced  froir  nracros 
because  they  represent  preoefinec  sets  of  code 
[GENTLEMAN  f.  hOcKSMA  831.  The  same  is  true  for 
library    routines    called    by    user's    program. 

3,1.2:    i2ki£!I££iaii£iD    2l   l2ii-.Lsy.2i    2£Ey.g.g.er 

Exception  cetection  is  essential  in  hardware 
because  potential  disaster  due  to  an  execution 
error  of  a  user's  program  can  be  avoided  in 
advance.  To  preserve  tne  integrity  and  to  enforce 
the  robustness  of  a  system)  some  restrictions  are 
imposed  oy  the  operating  system  on  a  user's 
program  in  the  form  of  exception  conditions. 
Whenever  one  of  these  conditions  is  fulfilled  by  a 
user's       program)  the      hardware         automatically 

generates  an  irterrupt.  When  this  interrupt  is 
triggered)  trie  supervisor  takes  control  of  the 
CPU  and  executes  the  appropriate  interrupt 
handling       routine       ana         a         user's  program  is 

terminated. 


This  interrupt  handling  routine  can  be  user- 
defined  i.e.)  a  user  can  specify  what  actionts) 
will    be    taken    wnen    an    irterrupt      occurs.         Actions 
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such  as  noting  »nere  an  error  occurred  ana 
printing  out  error  messages  are  possible.  But 
note  that  only  actions  whicn  can  be  performed  by  a 
user's    program    are    allowea!  otherwise      cascading 

interrupt  nandling  calls  can  result.  The  system 
or  default  interrupt  handling  routine  usually 
gives  an  exception  code  and  gracefully  terminates 
the      user's      program.         Examples       of  exceptional 

events         are:  illegal       irstruction       (  i.e..         an 

instruction      unknown         tc         system),  privileged 

operation  (i.e..  an  instruction  which  must  be 
executed         through  the  operating  system), 

addressing         (i.e.,  the       specified      address       of 

instruction  or  data  for  storing  and  fetching  is 
out  of  oouno),  specification  (i.e.,  something  is 
wrong      with      the       way       in      which       an      operand  is 

specified  in         an  instruction),         data       (i.e., 

illegal  data  format  for  certain  operation), 
arithmetic  overflow  and  underflow,  and  so  forth 
[STKUBLfc    75). 


Since      a      memory      auinp       is       a       copy       of  the 

program's  state  at  the  time  tnai  program  is  halted 
by  an  interrupt,  the  dump  is  normally  in  the  form 
of         numbers  lot         certain         base)  instead      of 

descriptive      messages      with         appropriate         values 
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associated.  This  is  because  not  much  conversion 
neeas  to  be  done  to  convert  the  machine 
representation  of  a  program  state  to  a  duirp. 
Within  this  dump.  there  is  a  completion  code 
(norrrally  part  of  Program  Status  Word.  PSW)  which 
indicates  the  reason  for  halting  the  program.  The 
contents  of  registers  (general  and  floating-point) 
are  also  avai  lable.  Through  the  values  of  these 
registers.  a  Better  insight  of  what  that  program 
was  doing  and  what  it  had  done  can  be  achieved. 
but  only  with  a  lot  of  sweat.  Furthermore, 
knowledge  of  the  usage  of  each  register  must  be 
known . 

3.2:   tiziiaaLe.  iucuati  lar.  Lam-leis!  Qfifcussiau 

Since  hardware  is  the  foundation  of  software. 

it    is   importart   to   investigate   how  hardware 

supports  can  be  employed  to  facilitate  software 
support  for  debugging. 

3.2.1:  &y.a.iJ.a.b.l£  daCUaaiS  iBSlS 

Some  hardware  supports  which  are  avai  lable 
include:  probes  to  detect  signals  to  and  from  the 
microprocessor.  a  fifo  buffer  for  logging  events, 
comparators    for    matching   patterns   (used   for 
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cond  i  t  i  ond  I  breaKpo  i  n  t  i  ng  ) »  timers  for 
performance  measurement  and  counters  for  measuring 
events  [GENTLEMAN  £  H0EKSM4  83].  Most  hardware 
tools  have  been  useo  for  logic  level  and 
functional  unit  level  hardware  debugging. 


Commercial  ir.-circuit  emulators  for 
m i cr opr cce sso r s  are  now  avai  lable  [INTEL  78J» 
[TEKTkONIX  81].  These  emulators  are  just  like 
probes  but  run  unaer  a  secondary  computer 
(microprocessor).  Sucn  emulators  can  monitor 
signals  i.e.t  generate  signals  to  the 
microprocessor  as  if  they  were  generated  from  the 
rest  of  the  circuitt  or  generate  signals  to  the 
rest  of  the  circuit  as  if  they  come  frorr  the 
microprocessor!  or  they  can  generate  both  types 
of  signals.  These  emulators  have  been  useo  widely 
for  debugging  simple  microprocessor  applications 
sucn  as  a  protocol  for  peripheral  control. 
Nevertheless?  the  application  of  these  emulators 
to  high-level  debugging  is  not  very  clear  because 
tney  are  net  widely  usee.  Certainly.  usage  of 
in- circuit  emulators  is  a  good  candidate  for 
concurrent  deougsiny  because  it  supports  an 
independent  process  running  on  a  different 
processor   rather   than   the   system  executing  the 
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concurrent  processes  that  are  being  debugged. 
Tnusi  witn  tne  inclusion  of  this  independent 
processor,  the  behavior  of  a  concurrent  program 
can  be  preserved.  In  other  words,  the  corcurrent 
program  can  be  deouggeo  without  any  modification 
at    all. 

For  instance,  suppose  a  concurrent  program 
is  running  on  a  systerr  and  an  emulator  is 
integrated  (into  that  system),  which  "listens 
to"  the  transactions  occurring  between  the  target 
processor  I  the  CPU  which  runs  the  concurrent 
program)  anc  other  parts  of  the  system.  With  this 
setup,  every  instruction  executed  by  the  system 
is  "overheard"  by  the  emulator.  Furthermore,  the 
emulator     is    an    autonomous    system,  its       listening 

will  not  affect  the  targeted  program  because  the 
emulator  is  not  interacting  with  the  running 
program.         Consequently,  the       concurrent    program 

can  run  uninterrupted  as  if  the  emulator  was  not 
ttiere  as  opposed  to  a  conventional  debugger  which 
is  embedded  (i.e.,  the  debugger  is  running  on  the 
same    processor    as    the    concurrent    program). 


This    mere    acility       to       "listen"       withcut       any 
interference      by       the       emulator       will     preserve    the 
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Behavior  of  tne  concurrent  program.  This  will 
definitely  nail  down  the  buy  residing  in  the 
targetec  system  because  there  shcula  not  be  any 
side  effect  produced  by  the  emulator.  Since  we 
are  interested  in  debugging  a  concurrent  program? 
whatever  tools  we  employ  must  not  create  any 
problem  so  that  the  program  can  Be  correctly 
debugged;  otherwise  the  bug(s)  is  not  eradicated. 
The  next  section  covers  a  detailed  application  of 
such  emulator  in  a  real  environment. 

3.2.2:  Usage,  fli  Ha.£2w.a££  I22J.S 

with  that  brief  introduction  to  the  hardware 
supports  for  debugging.  we  are  now  ready  to  see 
how  they  can  be  incorporated  into  a  system  for 
debugging  purposes. 


The  use  of  anotner  computer  to  monitor  real 
time  programs  is  described  in  [PL^TTNER  84].  He 
uses  a  probe  for  "listening"  to  the  transactions 
occurring  Between  the  target  processor  and  other 
part  of  the  system.  and  a  dual  port  Ipnantom) 
memory  wnich  is  a  memory  that  can  be  accessed  by 
both  monitor  process  and  target  processor 
interface.   The  phantom  has  the  same  wcrd  size  and 
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the  same  adcressing  range  as  the  target  processor. 
Tne  structure  of  his  monitor  is  given  in  Figure 
3.0. 

Moritoring  System 


BreaK  po  i  n  t  register 
>!       i 
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Figure    3.0:       Real-time    monitor    hardware. 


with  the  target  processor  interface  in  the 
monitoring  systerr  connected  to  the  target 
processor)  all  memory  transactions  generated  by 
the  target  processor's  CPU  are  "listened  to."  The 
information  involved  in  the  memory  transactions 
viz.i  its      adaress*         content      ana      whether       the 

location     is    read/write,       are    queued     in       the      FIFO. 
The       queued       data       then       f  lows       into       the       phantom 
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memory.  Tne  monitor  process  may  read  the  content 
of  tne  phantom  memory  at  any  time.  It  iray  lock 
tne  flow  of  data  from  tne  FIFO  to  the  phantom  by 
locking  the  FIFO.  During  such  a  period)  arriving 
information  to  the  UFO  is  queued.  If  the  FIFO  is 
unlocked  then  data  again  can  flow  to  the  phantom 
memory.  Since  the  monitor  process  is  "observing" 
the  targeted  processor  state  and  evaluating  the 
predicates  (commands)  that  were  suomitted  by  an 
operator.  the  ironitor  process  has  to  interpret 
on-line  the  low  level  (close  to  machine) 
information  availaole  in  the  phantom  memory  and 
perhaps  at  the  output  of  the  FIFO  in  order  to 
construct  a  hign  level  (close  to  target  prograrr 
source  level)  image  of  the  target  process'  state. 
The  interest  of  now  to  construct  a  hign  level 
image  is  a  totally  different  topic  from  our 
discussion  of  concurrent  debugger  but  for 
interested  reader  please  refer  to  [PLATTNEK  84). 
However)  to  speed  up  the  monitor  process)  a 
multiple  oreakpoint  register  is  connected  to  the 
output  of  the  FIFO.  This  oreakpoint  register 
reports  to  the  monitor  any  memory  transactions 
referencing  a  location  belonging  to  a  previously 
defined  set  of  memory  locations  for  breakpoints  by 
a   programmer  who  is  observing  the  behavior  of  the 
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target  processor 


After  the  irtegration  of  these  componerts» 
how  are  we  going  to  Know  that  the  rronitoring 
system  will  work  correctly?  Definitely,  testing 
of  the  monitoring  systetr  is  also  required.  If 
there  is  any  error  encountered  during  the  testing 
then  dedugging  the  system  is  necessary. 
Approaches  to  debugging  a  hardware  system  without 
having  to  resort  to  expensive  coirmer  c  ia  I  ly 
available  ceve I ocmen t  systems  is  descrioeo  in  the 
monograph  compiled  uy  Noordin  Gnani  and  Edward 
Farrel!  [GUAM  i.    FARRELL  oC]. 
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Chap t er  4 
Current  Tecnniques  In  Enhancing  A  Debugger 


As  time  elapses?  more  technology  is 
invented.  Consequently  this  new  technology  may  be 
usea  to  enhance  existing  systems  if  the  technology 
is  suitaDle.  With  the  advancement  of  database 
systems,  graphics?  and  Know  I edge-oasea  (expert) 
systems?  radical  enhancements  for  debuggers  seem 
prom i  s  i  ng. 

In  this  chapter?  we  investigate  the  prospect 

of    such   technology  being   used   to   enhance   a 

debugger.   First?   we  cover  how  the  knowledge  from 

database   systems  can  be  employed  in  the  debugging 

process.  Secondly?  graphics  technology  is 
reviewed  and  thirdly?  knowledge  engineering  is 
invest  i  gat ea. 

a.i:  a  Uaiauais  Causi  al  UekuaaLna 

A      database       is      a         repository         of  highly 

organized  information  wnich  provides  for  easy 
retrieval  and  maintenance  of  the  information.  The 
system         which         facilitates  the       retrieval       and 
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maintenance  of  Mgnly  organized  information  is 
called  database  management  system  (DBMS), 
Retrieval  and  maintenance  of  information  in  a 
database  is  accomplished  through  the  query  and 
update  facilities  provided  by  a  database 
management  system. 

In  debugging  a  program,  it  is  necessary  to 
have  access  to  information  about  the  source 
program  and  the  execution  state  of  that  program. 
If  we  could  somehow  translate  the  necessary 
information  for  debugging  a  program  into  a  form 
that  could  reside  in  a  Database,  then  debugging 
could  be  accomplished  by  performing  queries  and 
updates  on  a  database  representing  a  program. 


Currentlyi  there  exists  such  a  programming 
system,  called  CMEGA  [POWELL  £.  LINTON  83),  which 
stores  all  the  information  of  a  program  (parse 
tree,  symbol  table  and  so  forth)  into  a  relational 
database  system.  In  this  environment,  a  program 
is  treated  as  a  group  of  objects  from  different 
classes  such  as  variables,  statements, 
procedures  ana  so  forth.  In  order  to  relate  these 
classes  together  in  an  effort  to  represent  the 
semantics  of  a  program,   relationships  among  these 
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classes  need  to  be  e  s  tat.  I  i  s  ne  d  . 


For  example)   some  of  the  relations  could  be 


procedures  (name)  parameters?  statements) 
statements  (statement.categoryi  symbols) 
variables  lnaciie>  type?  value). 


In  tnis  example.  tne  'procedure'  relation 
has  three  attributes  viz.i  name)  parameters  and 
statements.  each  tuple  of  the  relation 
corresponds  to  a  procedure  in  a  program.  A 
procedure  has  a  rame»  some  parameters  (possibly 
none)  and  an  ordered  list  of  statements  which 
represent  the  body  of  a  procedure.  In  the 
'statements'  relation*  we  have  a 
sta temen t_ca tegor y  (assignment)  control) 
invocation  and  so  forth)  and  a  list  of  symbols 
making  up  a  statement.  On  the  other  hand)  the 
'variables'  relation  has  three  attributes.  The 
first  attribute  is  "name)"  which  can  be  a 
procedure  name  cr  a  symbol  in  the  symbol  list  of 
'statements'  relation.  The  second  and  third 
attributes  of  'variables'  relation  hold  the  type 
property  of  a  variable  (such  as  integer)  real) 
boolean  ana  so  forth)  ana  the  value  of  a  variable 
if  it  has  one. 


3<i 


A  query  language  is  used  to  forrrulate 
questions  aoout  information  in  a  database.  For 
instance,  if  we  want  to  find  all  the  statements 
where  procedure  'Dugs'  is  invoked.  we  could 
express  the  query  as  follows  in  a  naive  version  of 
QUEL  (the  query  language  tor  INGRES)  [INGRES  B5] 
as  follows: 


range  of  p  is  procedures 
range  of  s  is  statements 
retrieve  Is. all)  where 

s.statenent.category  =  'INVOCATION' 
and  s.symbolil]  "  'bugs'. 


In  this  example,  we  assume  the  procedure 
ndme  is  stored  in  the  first  position  of  the  symbol 
list  if  the  statement  is  an  invocaticn  statement. 
Furthermore,  a  user  is  expected  to  know  how  the 
relationships  are  set  up,  especially  the 
attributes  in  each  relationship  and  how  the 
relationships  are  linked  together  to  represent  the 
entire  program.  As  a  result,  a  user  has  to  know 
the  detail  of  the  database  like  the  name  cf  each 
relationship,  the  key  to  each  relationship.  Also 
knowledge  cf  the  compiler  mignt  be  helpful 
especially  in  understanding  how  the  relationships 
are   constructed   out   of   the   grammar    of    the 
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programming  language. 

In  order  for  a  user  to  debug  his/her  prograir» 
the  information  about  the  program's  state  must  be 
incorporated  into  the  database  so  that  a  query  can 
be  performed.  However  i  dynamic  information  is 
NOT  actually  stored  in  the  database!  but 
accessible  only  from  the  memory. 

The  organization  of  debugging  in  OMEGA  is 
depicted  in  Figure  <t.u. 
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Figure  4 . 0 :  Organization  of  debugging  in  OMEGA. 
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In  this  desiyn,  the  catabase  system 
interacts  w i t h  the  program  monitor  (aebugger)  to 
acquire  tne  dynamic  state  of  an  executing  program. 
The  prograii.  rrcritor  provides  relations  such  as 
valueof  (variablelD,  value)  which  is  transparent 
to  a  user  but  Knohn  tu  the  database  system  as 
collection  of  relations  that  are  physically 
separate  from  the  rest  of  the  database.  For 
instance,  tc  display  the  value  of  a  variable 
during  a  debugging  session»  a  user  queries  the 
system  to  retrieve  the  attribute  "value"  from  the 
appropriate  tuple  in  the  'variables'  relation. 

range  of  v  is  variables 

retrieve  v. value  where  v. name  »  'var.name' 

Tne  DBMS  then   sends   a   request   to   the   program 

monitor   for   the  value  portion  of  the  appropriate 

tuple.   The  monitor  then   returns   the   variable's 

value  from  the  executing  process  by  looking  up  the 

value  attribute  associated  with  that   variable   in 

the  'valueof'  relation  in  the  monitor.   That  value 

is  returned  to   the   DBMS   and   displayed   in   the 

appropriate    format   for   the   type   of   variable 

defined  in  'variables'  relation. 


In  this  environment,   a  user   is   allowed   to 
specify   a   set  of  actions  to  be  executed  whenever 
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tne  condition  (event)  specified  Dy  a  user  is 
reached.  An  event  is  a  condition  which  the  user 
is  interested  in  and  is  expressed  as  a  relational 
qualification.  A  condition  is  specified  in  a 
'when'  clause.  For  exairple.  to  have  the 
program's  line  number  displayed  when  the  procedure 
'Dugs'  is  invoked.   we  might  have  a  query  like 


range  of  ap  is  active-procedures 
when  I ast (ap ) .procedure  ■  "bugs"  do 

display  last(ap). 
end  . 


Here  we  assume  that  the  debugger  keeps  track 
of  a  relation  for  active  procedures  which  is 
defined  to  oe  ordered  in  such  a  way  that  the  first 
tuple  represents  the  main  procedure  and  the  last 
tuple  is  for  the  currently  active  proceoure  In  a 
call  chain  which  behaves  like  a  stack. 

With  this  type  of  query.  some  questions  that 
cannot  be  structured  in  a  conventional  debugger 
con  now  be  handled  elegantly.  Examples  of  such 
questions  include:  "when  will  procedure  P  be 
called  from  procedure  U?"  and  "What  are  the 
parameters  associated  with  procedure  P?". 


Unfortunately?   a  query  is   quite   wordy   and 
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this  approach  is  not  very  user-friendly  at  all. 
Consequentlyi  Powell  and  Linton  prefer  a  visual 
interface  so  that  a  user  can  construct  a  query 
from  objects  in  several  windows  on  the  screen  by 
using  a  mouse.  In  order  to  use  multiple  windows 
some  graphical  tool  is  necessary!  otherwise 
management  of  windows  is  intractable. 

4,2:  Graphical  Supports  £21  Debugging. 


A  visual  interface  to  debugger  is  very 
attractive  because  it  aids  in  creating  a  user- 
friendly  environment.  The  user-friendliness 
arises  from  the  ease  of  systeir  interaction  by 
using  graphical  objects  on  the  screen  (thereby 
hieing  details)  and  the  selection  of  graphical 
objects  by  using  a  pointing  device  such  as  a 
mouse.  The  use  of  graphics  and  a  pointing  device 
make  the  process  of  interaction  simple  and 
natural.  Graphical  objects  can  be  icons, 
windows.  graph,  etc.  Such  graphics  is  made 
possible  through  the  ability  to  allow  the 
brightness  of  every  discernible  point  in  the 
displayed  image  to  be  independently  controlled. 
For  an  introduction  to  computer  graphics,  please 
refer  to  [It, GALLS  81  J. 
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with  the  graphics  technology  at  our  disposal, 
multiple  ninaows  o(  various  sizes  on  a  screen  are 
attainable.  Further  more,  the  overlapping-window 
paradigm  for  a  user  interface  developed  Dy  Alan 
Kay  [KAY  t.  uGLDbEKG  77],  allows  information  from 
different  sources  to  be  displayed  simultaneously 
while,  at  the  same  time,  screen  space  is  used 
econo,:ii  ca  I  I  y  [TESLEk  81  ]  . 


To  manage  these  multiple  windows,  windowing 
systems  are  built  from  the  concept  of  multiple 
losus  running  concurrently.  Each  task  represents 
a  Different  window  anu  so  can  be  switched  freely 
between  tasks  by  switching  between  windows.  Such 
multiple  windows  tasking  are  supported  by 
SMALLTALK  [TESLEK  61)  and  XEROX'S  LOOPS  [6CBR0W  £ 
STEFIK  83].  Consequent  I  y  ,  this  approach  is  of 
great  value  in  debugging  because  the  user's  need 
of  information  simultaneously  gathered  from 
different  sources  for  debugging  is  now  available 
on  a  single  CRT*  This  approach  is  used  in 
instituting  a  "paperless  programming"  environment 
whereby  program  listings  or  information  is  no 
longer  needed  during  every  phase  of  the 
development  and  rraintenance  of  programs. 
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The  idea  ot  "paperless  programming"  is   being 
applied   in   the   Blit  debugger  [CARG1LL  83]  for  C 
programs.    The   olit   debugger   uses    a    multi- 
processing  bitmap  terminal.   When  Slit  (teririnal) 
is  connected  to  a  oort  IRS232)  of  a   UNIX   systemi 
a  program  in  Blit's  ROM  may  be  used  to  comirun  i  cate 
witn  the  UNIX  host  and  download   binary   code   for 
execution   in   blit.    Furtnerirorei    if   a   small 
multi-processing  nemeli   rtpx*  is  loaded  to   8lit> 
Mpx  can   run   in   cooperation   with   corresponding 
software   invoked   on  the  UNIX  host.   Mpx  allows  a 
user  to   define   and   manage   a   set   of   possibly 
overlapping   windows.    Alsoi    Mpx   runs  a  simple 
process  which  communicates   with   a   copy   of   the 
standard   UNIX   command   interpreter  SHELL.   As  a 
result,    a   user   can   treat   each   window   as   a 
separate     terminal    and    engage    in    several 
simultaneous  conversations  with   UNIX   and   remote 
machines  connected  to  the  host.   Furthermore,   the 
terminal  processes  may  be   replaced   by   arbitrary 
programs   downloaded   from   tne   host   to   exploit 
Blit's     graphics     ano     local      processing. 
Essentially,         these      processes      execute 

*  Designed  and  implemented  by  Rob  Pike. 
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asynchronously  while  Mpx  arbitrates  the  use  of  the 
keyooarc  ana  mouse>  ana  multiplexes  corcir.un  i  ca  t  i  on 
with  t  no  host. 

The  aecugger  is  aiviuea  between  two 
communicating  processes  i.e.)  one  in  the  Bl  it  ana 
the  other  in  the  host  (UNIX).  The  process  in  the 
Blit  interfaces  with  the  keyboard)  mouse  and 
display)  ana  has  access  to  the  process  being 
debugged  ana  Mpx.  The  communicating  process  of  the 
debugger  in  Blit  acts  as  a  front-end)  carrying 
out  commanos  issued  Dy  the  host  process.  Since 
Mpx  manages  the  keyooarc  and  display  (CRT))  the 
debugger's  I/O  will  not  interfere  with  that  of  the 
process  being  debugged  even  when  both  are  active 
simultaneously.  However)  logical  control  of  the 
debugging  rests  with  the  communicating  process  on 
the  host.  The  communicating  process  of  the 
debugger  on  the  host)  has  access  to  the  file 
system  and  thus  the  symbol  tables  of  the  program 
being  debugged  anc  has  responsibility  for  almost 
all  aecisions  calling  for  semantic  interpretation 
of  the  program  Deing  debugged. 


The  debugger  can  be   loaaec   whenever   it   is 
requirea   and   applied   to  any  desired  process  for 
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debugging.         Once       it       is       in       blit,  it       can      be 

retained  and  applied  to  different  processes  in 
turn.  This  is  possible  because  Mpx  can  pass  the 
debugger  a  pointer  to  the  process  descriptor  of  a 
window    picked    by    a    user. 

4.3:       linaji.I.e.dcje.-b.a.S.e.d    Qflflsl    2i    DsEuaaiflS 

The    research     in    Artificial     Intelligence       (AI) 
is         now       being       applted       to       other       areas.  This 

technology  includes  the  areas  of  problem  solving, 
Knowledge  representation!  natural  language 

understanding,  perception,  learning,  etc.  For 
further  information  about  this  technology,  refer 
to    LR1CM    S3  J. 

Currently,  tne      main       AI       technique         being 

applied  to  program  debugging  is  the  concept  of 
know  I  edge-basec       systems.  Two  knowledge-based 

systems  that  deal  with  program  bugs  are:  PRDUST 
(Program  Understander  for  Students)  [JDhNSON  i. 
SOLUWAY  85]  and  FALUSY  (Fault  Localization  System) 
[SEbLMEYER    et    al     b3 J  . 

A         Know  I edge-oase  is         a         repository         of 

declarative    or    procedural     cefinitions    of    Knowledge 
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ana  is  dynamic  [Sl*«  B 't  j  .  Declarative  Knowledge 
is  concerns d  with  tne  "what"  or  "knowing  that"» 
whereas  procedural  Knowledge  is  concerned  with  the 
"how"  or  "knowing  how".  As  an  example)  [SIMON 
691  cited  tne  following  two  specifications  for  a 
circle  ip.  111). 


A  circle  is  tne  locus  of  all  points  equidistant 
f r  om  a  a  i  ven  point. 

To  construct,  a  circlet   rotate  a  compass  with  one 
irrr.  fixed  until  the  other  arm  has  returned  to 
its  starting  point. 

The  first   sentence   is   a   declarative   knowledge 

while  the  seconu  is  a  proceoural  one. 


Now»  what  is  the  difference  Between  a 
database  syslerr  [4.1]  and  a  knowledge-based 
system?  John  Sowa  [SOWA  B<t  >  277]  differentiates 
the  two  as  follows: 


In  database  systemsi   "the  user  must  know  what 
to  ask  for  ana  what  to  do  with  the  results." 
In  knowledge-based  systemsi   the  systems  "keep 
track  of  the  meaning  of  the  data  and  performs 
inferences  tu  uetermine  what  information  is 
needed  even  when  it  has  not  been  explicitly 
requested." 


A. 3.1:  PRytJiT  (Program  on  de£s  tande  r  for  Siudent) 
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PR0U5T  is  a  k now  I e eg e-base d  system  that 
attempts  to  t i no  cugs  in  PASCAL  programs  written 
Dy  novice  programmers,  linen  a  bug  is  aetectedi 
PROUST  determines  how  the  oug  can  be  corrected  and 
suggests  why  the  oug  arose.  PRCUST  accomplishes 
its  goal  by  employing  a  knowledge  base  of  common 
programming  "plans."  These  "plans"  are  selected 
to  tackle  a  specific  programming  problem  which  has 
been  defined  into  PkOUST's  problem  description. 

This  knowledge  of  a  problem's  definition 
makes  the  variaoil  ity  of  novice  solutions  more 
manageable  ana  provides  important  information 
about  the  programmer's  intentions.  To  supply 
PROUST  with  descriptions  of  the  programming 
problems*  a  problem  description  language  is  used. 
Each  problem  description  is  a  paraphrasing  of  the 
English-language  problem  statement  that  is  hanaed 
out  tc  students.  The  problem  description  consists 
of  programming  goals  and  sets  of  data  objects. 
Programming  goals  are  the  principal  requirement 
that  must  be  satisfied;  sets  of  data  objects  are 
the  data  that  the  program  must  manipulate. 


An  example  of  how  goals  are  extracted  from   a 
problem  statement  is  demonstrated  by  the  following 
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[JOHNSON  I    SOLOWAY  a 5 1  p  1831! 


Problem  statement  : 

Write  a  prograir  that  reads  in  a  sequence  of 
positive  numbers*  stopping  when  99999  is 
read.   Compute  the  average  of  these  numuers. 
Do  not  include  the  99999  in  the  average. 
3e  sure  to  reject  any  input  that  is  not 
pos  i  t  i  v  e  . 

Ex  trac ted  goa I s  : 

-  Read  successive  values  of  New,   stopping 
when  a  sentinel  value,  99999  is  read. 

-  Make  sure  tnat  the  condition  New  <-    0 
is  never  true. 

-  Compute  the  average  of  New. 

-  Output  the  average  of  New. 

*  Note  :  Sentinel  value  is  a  value 

which  signals  the  end  of  input. 

From   these   goals,    a   problem   description    is 

generated  for  PROUST.   In  the  problem  description, 

each  data  object  to  which  the  goals  refer  is  named 

and  declared.   Also  each  goal,   extracted  from  the 

problem  statement,   is   recorded   In   the   problem 

description.    With  these  goals  identified,   plans 

must   be   selected   from   the   Knowledge   base   to 

implement   these  goals.   PROUST  uses  a  frame-based 

[MINSKY  7b]  programming  knowledge   which   consists 

of  goals  and  plars.   Plans  are  stereotypic  methods 

for  Implementing  goals. 


Once  a  problem   description   is   defined   and 
before   any   analysis   of   goals   and   plans  takes 
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placet  a  student's  PASCAl  program  is  parsea  ana  a 
parse  tree  is  produced.  This  parse  tree  is  then 
operated  on  during  subsequent  analysis  of  the 
program.  when  PkfjUST  analyses  a  program)  it 
selects  goals  from  the  problem  description  one  at 
a  time.  As  a  soal  is  selected.  PROUST  retrieves 
from  its  programming  Knowledge  base.  plans  that 
could  be  used  to  implement  the  goal.  If  the  plan 
matches  the  program.  then  PROUST  proceeas  and 
selects  tne  next  goal;  otherwise  a  different  plan 
is  retrievec.  If  none  of  the  plans  matches  the 
program.  PROUST  must  look  for  bugs  that  account 
for  tne  it  i  s  match  in  one  of  the  plans. 

when  PROUST  encounters  plan  differences.  it 
does  not  give  up  on  the  plan;  instead.  it  tries 
to  find  a  way  of  interpreting  the  plan  differences 
as  bugs.  Plan  differences  are  explained  by  means 
of  bug  rules.  Eacn  bug  rule  has  a  test  part  which 
examines  the  plan  differences  to  see  whether  the 
rule  is  applicable.  and  an  action  part.  which 
explains  the  plan  differences. 

<t.3.2!     fausi     (Eauii  Lasaliialiaa  ixsisa) 

FALOSY  is  3       very   specific   fault   locating 
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system  limited  to  master  file  update.  The  general 
master  file  update  programs  involve  the  updating 
of  appropriate  taster  records  to  reflect  the 
activities  represented  Dy  the  cor r espon c i ng 
transaction  records  from  a  set  of  master  files  and 
a  set  of  transaction  files  respectively.  FALOSY 
identifies  the  statement  of  master  file  update 
program  statements  whicn  cause  anomalous  behavior. 
This  identification  of  statements  is  accomplished 
by  a  knowledge-based  model  which  includes  the 
integration  of  prototypic  ano  causal  reasoning 
about  faults  and  a  r ecogn i t i on-baseo  mechanism  for 
program  abstraction.  The  methoc  of  abstraction  is 
done  by  using  a  recognition  method  in  which  source 
statements  are  matched  tc  functional  prototypes. 
Eacn  functional  prototype  consists  of  four 
component  s  name  I y 


a)  a  set  of  recognition  triggers, 

b)  a  description  of  intencea  behavior? 

c)  a  description  of  expected  structure  and 

d)  a  list  of  constraints  which  must  be  satisfied  to 
ensure  that  the  candidate  structure  represented  an 
instance  of  the  prototype. 


To  uetect  a  fault,  analysis  of  output 
discrepancy  is  needed.  Through  this  analysis,  an 
initial  localization  tactic  is  selected.  The 
localization   tactic   is   a   method   used  to  focus 
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attention  on  suspicious  program  statements.  Tn  i  s 
analysis  procuces  a  description  of  the  differences 
between  expected  and  observed  outputs.  It  also 
generates  a  set  of  fault  hypotheses»  which 
consist  of  a  functional  prototype  and  an  expected 
defect.  Fault  hypothesis  is  tested  by  determining 
if  the  expected  defect  is  present.  If  a  defect  is 
detected  through  that  hypothesisi  then  the 
hypothesis  and  the  erroneous  program  state mentis) 
is  output  ana  the  program  stops!  otherwise 
current  localization  tactic  is  reevaluated  to 
select  next  available  fault  hypothesis.  If  a 
localization  tactic  is  retained  then  it  is  used  to 
generate  the  next  nypothesis;  otherwise  a  new 
tactic  is  selected.  However)  if  no  more 
plausible  hypothesis  can  be  mace  then  localization 
terminates  with  an  appropriate  message.  The  logic 
of  this  fault  localization  prccess  Is  depicted  in 
F  i  gure  4.1. 


YES 


/  ADandor,   \ 

\  Tactic?   /   NQ 


Select 
Tactic 


Generate 
Hyp  o thes  i  s 
set 


/  Hypotnesis\ 

->/      set      \. 

\     empty';    / 

\ / 

V   MO 


Propose 
Hy pothes  i  s 


./  Hypothesis   \ 
\  Verification/ 


YES 


V    YES 


Report    Fault 

Ana  lysis 

( 


Repor  t 

Fa  i  lure 

(_. 


Figure    4 . 1 :     The    fault     localization    process. 
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K  i  tfi    the    aatabase    model    of    debugging*        it       is 
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possible  to  construct  some  powerful  queries 
(complicateu  ones)  that  cannot  be  carried  out  by  a 
conventional  debugger  because  the  information  of  a 
program  is  properly  organized  for  easy  retrieval 
and  maintenance.  Unfortunately!  a  query  is  quite 
woroy  and  a  user  needs  to  Know  now  the  database  is 
organized  so  that  a  proper  query  can  be 
constructed  to  retrieve  pertinent  i  nf  o  rrra  t  i  en  . 

Graphical  supports  for  debugging  is  an 
excellent  form  of  interface  between  user  and  the 
debugger.  Morecveri  "paperless  programming" 
seems  promising  witn  the  help  of  computer 
graphics. 

with  the  ability  to  represent  some  Knowledge 
of  a  program  in  a  debugger*  debugging  a  program 
can  be  automated  <inj  suggestions  can  automatically 
be  generated  concerning  possible  remedies  to 
correct  a  program's  behavior.  But  current 
"automated"  debuggers  are  tailored  for  only 
specific  programs  and  not  generic  ones. 


ConseqLentlyi  a  database  model  is  good  for 
constructing  powerful  queries  and  could  be  of 
great   nelp   In   uebugging   a   concurrent   program 
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because  multiple  processes  are  involved.  These 
multiple  processes  are  often  instances  of  a 
specific  process  type.  Thusi  each  instance  can 
be  representee  as  a  record  in  a  database  file  for 
tnat  specific  process  type  with  process 
identification  as  key  to  each  record.  Graphical 
support  is  definitely  an  asset  in  debugging  a 
concurrent  program  because  the  source  text  of  each 
process  can  be  viewed  simultaneously  when  rrultiple 
windows  are  possible.  Furthermore)  knowledge- 
based  mocels  of  debugging  will  be  of  interest  in 
debugging  concurrent  programs  so  that  concurrent 
semantics  checking  can  be  automated  to  forewarn 
user  of  potential  problems. 
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Chap  t  er  5 
Feature  and  implementation  issues  of 
a  debugger  ror  Concurrent  C 


5.1:  iQir.fld.^c.tifin. 

The  differences  Between  a  concurrent  program 
and  a  sequential  ore  are:  i)  a  concurrert  program 
is  composed  of  multiple  sequential  programs 
running  concurrently*  and  iil  these  multiple 
sequential  programs  typically  communicate  Between 
themselves  via  messages  llike  Concurrent  C)  or 
shared  memory  (as  with  Concurrent  Pascal). 
Consequently*  errors  encountered  in  sequential 
programs  are  alsc  possible  in  concurrent  programs. 
However,  some  other  errors  that  CANNOT  happen  in 
sequential  programs  can  occur  in  concurrent 
programs . 

5.2«  Cai£fi£Li£5  ai  slieis 

Errors  can  De  placed  into  two  main 
categories*  namely,  concurrent  errors  and 
sequent  ia I  errors. 

Concurrent  errors  are  errors  that  can  occur 
ONLY   in  concurrert  programs  and  NOT  in  sequential 
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programs.  Concurrent  errors  can  be  subdivided 
into  two  groups  which  are  race  conditions  and 
deadlocks.  A  race  condition  error  is  concerned 
with  an  error  which  arises  due  to  a  timing  problem 
(refer  to  Chapter  1  for  more  details  about  timing 
problems).  A  deadlock  errcr  is  concerned  with  the 
non-progress  of  an  executing  concurrent  program. 
(ton-pr osress  means  a  subset  or  all  of  the  multiple 
sequential  programs  within  a  concurrent  program 
cannot  make  any  progress.  Essentially?  these 
sequential  programs  are  waiting  for  some  events  to 
occur  before  they  can  proceed. 

Sequential  errors  can  occur  in  both 
sequential  and  concurrert  programs.  These  errors 
come  in  many  forms  but  me  common  ones  which  have 
been  encountered  oy  the  author  are: 
initialization  error?  misiratched  error,  pointer 
error,  range  error,  arithmetic  error,  and 
output  error. 


An  initialization  error  arises  due  to  a 
missing  or  wrong  initialization  of  some  program 
variables.  This  type  of  error  could  cause,  for 
example,   infinite  looping  and  subscript  error. 
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A  mismatched  error  is  concerned  with  an  error 
which  arises  because  a  condition  NEVER  Decorres 
true.  Such  error  could  result  in  the  failure  to 
exit  a  loop  (infinite  looping),  or  an  unintended 
execution  path  to  be  followed. 

Pointer  errors  arise  due  to  incorrect 
addressing.  A  pointer  error  could  cause,  for 
instance,  system  interrupts  (i.e.,  a  type  of 
exception  handling)  or  coce  to  be  overwritten. 

A  range  error  is  mainly  concerned  with  some 
subscript  Being  out  of  bound  or  an  invalid  value 
for  3  variable.  Its  effect  is  a  system  interrupt 
or  corrupted  data  retrieval  during  indexing. 

An  arithmetic  error  is  concerned  with 
arithmetic  overflow/underflow  and  division  by 
zero.  Its  effect  includes  precision  problems  and 
a  system  interrupt. 


Uutput  errors  arise   cue   to   a  computation, 

logic   or   forrratting   errcr.    Sucn  errors  could 

cause  the  program  to  Be  rewritten,  personnel   to 
point  fingers  at  one  another,   etc. 
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5.3:   lQiiiisisiyaG.*  si  S£o.y.£Qiial  astijuasis   in  2£iiiaa 

ilia  iii^ijLLiii   Li^aijii 


With  the  identification  of  possible  errors  in 
concurrent  and  sequential  programs!  it  is  obvious 
tnat  the  mechanisnr  employee  in  a  debugger  (or 
sequential  prograrrs  is  NOT  capable  of  debugging 
concurrent  programs.  This  is  because  a  sequential 
debugger  lacks  ihe  ability  to  handle  multiple 
processes       [sequential       programs)       at  the         same 

instance.  For  example?  dbx  (a  debugger  for  C) 
cannot  be  used  to  debug  a  Concurrent  C  program. 
Howevert  the       features      exhibited       in     sequential 

debugyers  can  be  employed  to  debug  parts  of  a 
concurrent       program.  This       is    possible    because    a 

concurrent  program  is  composed  of  multiple 
sequential  programs.  Nevertheless?  additional 
features      whicn      are         essential  for         debugging 

concurrent    programs    must    also    be     incorporated. 

5.4:    miQ.    l£  a  lulls.    io.i    a    C.p.nc.yr.r.e.nl    C.    jfitjuiiJiil 

Since  a  concurrent   program   is  composed   of 

multiple   sequential  programs  called  processes  lin 

Concurrent  C  and  Concurrent  Pascal)>  the   ability 

to   visualize   the  state  of  each  and  every  process 

at  any  one  instance  is  essential    in  debugging   a 
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program.  This  capaDility  is  essential  In  oraer  to 
pinpoint  which  processus)  is  causing  the  program 
to  Behave  anomalously  by  examining  the  state  of 
each  process.  Furthermore)  these  processes  can 
communicate  among  themselves  which  makes  debugging 
more  difficult  and  often  very  tedious.  The 
availability  for  examination  of  each  process' 
state  at  any  instance  will  facilitate 
identification  of  the  culprit  process  by  a 
relative  comparison  of  the  state  of  each  process. 
This  ability  is  very  useful  in  assisting  in  the 
localization  of  deadlock  or  detection  of  an 
unwanted  race  condition)  both  of  which  are 
frequently  ercountered  in  concurrent  programming. 

5.4.  li  "Cie.I2il-Y.iSH"  acc£0ic.h  at  B.r.oc.e.s.s.e.  s.  tiUtilMI 

d  euug.sin£ 

with  tne  state  of  each  and  every  process 
visible  at  any  one  instance)  we  can  deduce  the 
cause  of  a  ceadlcck  or  unwanted  race  conaition. 
The  comparison  of  these  states  will  help  to  reveal 
tne  events  causing  the  deadlock  or  unwanted  race 
cond  i  t  ion. 

As  an  example)  assume  that  we  have  four 
processes   whicn   simulate   a   token   ring  network 
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environment  with  each  process  representing  a  node 
of  the  network  (see  Figure  5.0a).  The  state  of 
processes  A,  C»  ana  0  reveal  that  they  are 
waiting  on  the  token  and  there  is  a  token 
currently  on  the  network  ring  since  process  b  is 
in    an    active    state. 


accept    F RUM_C 
---[A] 


[B  ]    active 


[CJ     accept    FR0M_D 


• [D] I 

accept  FRCM.B 

Figure  5.0a:  A  deadlock  with  all  process  states 
D  e  i  n  g  visible 


with  tne  state  of  each  ana  every  process 
being  v  i  s  i  o I e  at  this  timet  we  can  infer  that 
process  B  is  tre  process  responsible  for  the 
deadlock.  This  is  because  processes  A?  C  and  D 
are  w  a  1 1  i  n  g  »  and  the  ONLY  active  process  at  this 
time  is  B.  Thus>  B  is  the  process  which  never 
releases  the  token!  Consequently?  the  other 
processes  cannot  proceed  and  the  result  is 
dead  lock. 


Suppose*    for   a   moment*    that   only    two 
processes'  states  are  visible  instead  of  all  four. 
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If  processes  C  and  D  are  the  processes  with 
visible  states  (see  Figure  5. Obit  then  we  nave  no 
iaea  which  of  the  other  two  processes  (i.e.>  A 
and  B )  is  the  culprit. 


■[Al- 


io] CO    accept    FRUM_D 


; [o] ! 

accept  FRCM_B 

Figure  5.0b:  A  oeadlock  with  partial  process  states 
being  visible 


5. a. 2:  Piassss  siaiss 

To  support  the  state  of  each  and  every 
process  being  visible  at  any  one  instance,  we 
neea  to  identify  the  necessary  states  which  will 
highlight  the  statLS  of  a  process.  Unfortunately, 
the  state  of  a  process  is  Dependent  upon  the 
context  in  which  it  is  used. 


5. 4. 2.1:  QEiLSiiQ2  SYii-Sffi's  Y.i£w.D.o.j.I)l.  at  a  iiats 
£i  a  o.rcces.s 


Fron  the  operating  system's  viewpoint,  a 
process  can  be  in  only  one  of  the  following 
states.  namely:  reaay,  running,  blocked  or 
hdltec   [DEITEL  n't).       A   process   is  in  the  ready 


state  it  it  is  waiting  tor  a  CPU.  A  process  is  in 
a  running  state  if  it  currently  possesses  a  CPU. 
When  a  process  is  said  to  Pe  in  tne  blocked  state» 
it  is  waiting  for  soire  event  to  happen  Isuch  as  an 
I/O  completion)  before  it  can  resume.  Lastly,  a 
process  is  in  the  halted  state  if  it  has  run  to 
completion.  These  four  states  are  needed  just  to 
facilitate  the  scheduling  of  a  process  oy  the 
operating  system. 

5.4.2.2:  Concurrent  C  '  s.  visa  2l  a  Q.L.£ces.s. '  SiSiS 


On  the  other  hand*  the  Concurrent  C  system 
is  aware  uf  UNLY  three  states  for  any  process. 
These  states  art;:  active,  completed,  and 
terminated  [GEHAI.I  L  KGOME  8  k  ]  .  An  active  state 
is  attained  whenever  a  process  is  created  and  the 
process  remains  in  this  state  while  executing  the 
statements  specified  in  the  corresponding  process 
body.  A  completed  state  is  reached  whenever  a 
process  executes  a  'return'  statement  in  its 
process  body  or  when  it  reaches  the  end  of  its 
body.  Finally,  a  terminated  state  is  a  state  in 
wh i ch  a  process  has  completed  and  all  the 
processes  created  by  it  (i.e.,  its  child 
processes)   have   terminated,    or   when  a  process 
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executes  a  r eao y-to- ter m i nat e  alternative  in  a 
'select'  statement  within  a  process  body.  These 
states  are  employed  in  Concurrent  C  system  so  that 
transaction  calls  to  active  or  terminated 
processes  can  oe  detected.  With  this  detectiont 
invalid  transaction  calls>  deadlockt  etc.»  can 
be  handled  gracefully. 

5.4.2.3:  IUfi  i£l££i£2  CI£££SS  SlSlSi  flf  S    CI2ESSS 

The  states  neeoeo  to  support  the  capability 
of  each  process1  state  being  visible  to  a 
programmer  in  Concurrent  C  at  any  one  irstance  are 
ouite  similar  to  those  mentioned  earlier.  Those 
previously  mentioned  states  have  been  refined  and 
can  be  placed  into  four  categories  viz.. 

a )  active 

b)  communicating  (rendezvous) 

c)  delayed  and 

d)  terminated 


An  active  state  is  a  state  in  which  the 
process  is  executing  some  instructions  but  which 
may  be  interrupted  for  swapping.  When  a  process 
has   started   up   (Dy   the   'create'   primitive  in 
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Concurrent  C).   it  is  in  ar  active  state.   Once  in 
the   active   state.    a  process  could  go  to  any  of 
the  other  states  depending   on   its   source   code. 
When   it   is   corrrrun  i  cat  i  ng   with   another  process 
(i.e.i   by  executing   a   transaction   call   or   an 
'accept'   primitive),    its   state   is   said  to  be 
•communicating.'    »hen   a   process   executes    an 
'accept'   primitive,   it  is  delayed  until  there  is 
a  corresponding  transaction  call  targeted  to   this 
'accept'     -     a   mechanism   for   rendezvous   in 
Concurrent  C   tGEHANI   t   ROOKE   841.    Similarly, 
when   a  process  executes  a  transaction  call  Iwhicn 
is  not  a  timed  transact  ion  I  i   it  is  delayed   until 
tne   transaction   call  is  complete  (i.e.,   until  a 
rendezvous  with  corresponding  'accept'   has   taken 
place    and   a   return   f  r  o  rr   the   rendezvous   has 
occurred).   In   a   timed   transaction   call,    the 
process   calling   the   transaction   is   allowed  to 
withdraw  the   transaction   call   if   the   targeted 
process   ooes   net  'accept'  the  transaction  within 
tne  specified   period   [GEHANI   E.   ROOKE   81],    A 
process   is   in   a   delayec   state   only   when   it 
explicitly   executes   a    'delay'    primitive    in 
Concurrent   C.    A   terninatea   state  is  in  effect 
whenever   a    prccess    executes    a    'terminate' 
primitive  or  reveries  tne  end  of  its  source  code. 
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5.4.2.4:   liieaLiaDtfi  at  ins  sslscisfl  ctflssss 
iiaifii. 


The  reasons  why  the  previous  four  states  are 
important  in  facilitating  the  debugging  of  a 
Concurrent  C  program  are  now  described.  An  active 
state  is  needed  so  tnat  we  know  tor  sure  that  a 
process  has  started  and  is  running.  Communicating 
and  oelayed  states  are  needed  just  to  give  the 
programmer  involved  in  debugging  a  sense  of  where 
the  process  is  executing  at  a  particular  time  -  it 
is  a  kind  of  a  sign  post  indicating  the  relative 
line  of  code  Deing  executed  within  a  process. 
These  two  states  are  chosen  because  they  are  usea 
very  often  in  Concurrent  C  as  means  of 
synchronizing  anc  c ommun i ca t i na  with  otner 
processes.  Lastly)  we  need  the  terminated  state 
just  to  notify  the  programmer  that  a  particular 
process  is  no  longer  of  interest  to  nim/her 
because  it  has  alreaoy  terminated.  with  these 
four  statesi  we  are  able  to  hide  details  which 
are  unimportant  to  a  programmer  at  the  stage  of 
locating  the  malicious  process(es).  This  is  an 
approach  to  state  aostraction. 

Since  »e  do  not  Know  which  of  the   processes' 
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states  are  necessary  in  orcer  to  facilitate  in 
debugging)  every  process'  state  is  displayed  at 
all  times.  Furthermore.  any  one  of  the  processes 
within  a  concurrent  program  has  a  potential  to  be 
the  culprit  which  causes  ar  error.  Thus.  some  of 
the  processes'  states  may  be  redundant.  but 
certainly  the  amount  of  information  presented  is 
adequate  to  infer  the  immediate  cause  of  a 
cascading  error.  A  cascading  error  refers  to  an 
error  which  propagates  through  one  or  more 
processes.  The  last  prccess  in  this  chain  of 
errors  is  tr.e  one  which  could  not  cope  with  the 
error  and  so  was  designated  as  the  immediate  cause 
of  the  cascading  error. 

This  approach    will    help    pinpoint    the 

malicious  process   but   it   does  not  pinpoint  the 

specific  line   of   code   within   a   prccess   that 

inherited  the  cascaaed  error(s). 


To  really  nail  down  the  error  to  a  particular 
line  of  code.  an  examination  of  tne  value  of 
variaoles  involved  in  tne  suspected  process  needs 
to  be  carried  out.  The  neea  to  examine  the  values 
of  variables  is  because  a  process  is  partly 
composed   of   variaules   anu   trie   value   of   each 
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variable  oeterrrines  the  Behavior  of  a  process.  In 
this  fashion,  he  are  employing  two  levels  of 
abstraction   -   a  zooning-in  approach. 

5.4.3:  iusESQSiac  2l  H    HL2UB  C.1  CLSJiSiSSS 

Besides  the  four  states,  we  still  need 
another  mechanism  to  help  in  debugging  a 
Concurrent  C  program.  This  mechanism  is  concerned 
with  how  to  temporarily  suspend  the  execLtion  of  a 
concurrent  program.  The  purpose  of  this 
suspension  is  to  permit  checking  the  value  of  some 
variables  or  even  the  state  of  each  process  in  an 
attempt  to  nail  down  a  trouolesome  statement. 

5.4.3.1:  £a.y.s.  Is  lliS2££  iUSB£Dii£n  at  a  SI.flii£  fit 
u,r  ocess.es 

Fortunately,  there  are  a  several  ways  to 
trigger  suspension  of  a  group  of  processes  or  a 
concurrent  program. 

Une  method  to  trigger  suspension  of  a  group 
of  processes  is  to  hardcode  a  "oreakpoint" 
instruction  in  each  piocess  body.  This  way  is 
static  ana  NOT  flexible  at  all.  Furthermore,  the 
source  cede  nceas   to   be   recompiled   every   time 
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there    is    a   change   in   trie   position   of   any 
breakpoint  in  the  code. 

A  better  approach  is  ty  Broadcasting  iressages 
to  all  of  the  existing  processes  involved.  The 
process  executing  the  breakpoint  instruction  has 
to  broaccast  a  m  e  s  s  a  g  e  >  to  all  existing  processes 
(within  the  Concurrent  C  program))  to  suspend 
themselves.  In  order  to  broadcast  the  message» 
there  must  be  a  global  table  which  indicates  which 
processes  are  available  so  that  the  broaccasting 
process  Knows  where  to  senc  the  messages.  This 
capability  of  knowing  where  to  access  the  global 
table  ana  how  to  send  the  messages  irust  be 
included  in  eacn  process.  This  approach  is  a 
decentralized  approacti  as  opposed  to  a  centralized 
approach  which  will  be  presented  later. 


The  time  delay  for  each  process  to  receive 
and  act  on  the  messace  may  be  different.  The 
difference  in  time  delay  is  due  to  the 
configuration  uf  the  processes  and  the  system's 
loau.  Fortunately)  this  aporoach  is  dynamic  and 
su  more  flexible.  It  is  dynamic  because  the 
message  to  be  sent  is  determined  by  the  global 
table   which  is  updated  while  a  concurrent  program 
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is  being   executed.    Moreover*    it   is   flexible 
because   the   routing  of  the  broaccasting  messages 
need  not  be  harocooed  as  the  routing  is  driven   by 
the    content   of   the   global   table.    The   only 
drawback   with    this    approach    is    that    its 
implementation    will   be   quite   hard.    This   is 
because  each  process  within  a   concurrent   program 
needs   to   have   a   way  to  receive  the  broadcasted 
rressage.   Apparently  this  approach  is   not   easily 
accorrp  I  i  shed    with    the   'accept'   primitive   of 
Concurrent  C  as  a  spontaneous  receipt  of  a  message 
is   impossible.    However,    there   is   a   way   to 
overcome   that   problem.    The   solution   is   that 
whenever  a  process  wants  tc  senc  a  tressage  related 
to  a  debugger  command  to   other   processes.    that 
message  is  sent  to  a  "nail  box"  process  which  acts 
on  benalf  of  the  receiving   processes.    In   order 
for   this   solution   to  work  correctly,   a  process 
must  periodically  check   in   with   the   "mail-box" 
process ■ 


Yet  another  way  to  trigger  the  suspension  of 
a  group  of  processes  is  by  usina  a  bottleneck 
approach.  In  this  case.  there  is  a  centralized 
process  which  provices  a  variety  of  services  to 
the  other   processes.    This   centralized   process 
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will  accept  a  request  from  all  trie  other  processes 
which  intenJ  to  execute  a  "Breakpoint"  instruction 
or  other  debusing  comrancs  handler)  o  y  the 
centralized  process.  Once  a  "Breakpoint" 
instruction  is  executed)  all  other  requests  to 
the  centralized  process  are  queued.  Consequently) 
all  other  processes  will  Be  suspenoed  or  delayed. 
This  method  is  quite  flexible  and  easy  to 
implement.  For  example*  in  the  kernel  approach 
to  structuring  Qn  operating  system*  a  numoer  of 
operating  system  processes  are  created  to  serve 
users'  processes  so  that  the  utilization  of  a 
system's  resources  can  be  improved  [OEITEL  63]. 
Thus  the  centralized  process  can  Be  created  as  one 
of  the  system  processes  to  serve  the  corcurrent 
processes  of  a  concurrent  program. 


5.4.3.2:  IHP.ort.ance  of.  suspending,  ail  ELS££S^es 

3yiiES  si    ElSStE.SiQ.i 


S  i  nr e  a  concurrent  program  is  composed  of 
multiple  processes*  a  temporary  suspension  of  a 
process  MUST  also  stop  all  of  the  other  processes 
frciii  executing  lest  suspension  violate  some  timing 
factors  involved  in  a  concurrert  program.  Such  a 
timing  violation  is  sure  to  occur  if  the  processes 
are  running  on  a  iru  1 1  i -processor  environment)   But 
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the  violation  is.  net  so  obvious  in  a  'quasi- 
parallel'  environment  (multiplexing  of  single 
processor). 

For   instance!  if   we   have   a    concurrent 
program   whose   source   code  Ipseudo  Concurrent  C> 

see  Figure  5.1a)  is  running   in   a   two-processor 

environment,    then  a  deadlock*  is  SURE  to  happen 

because  processes  2  and  3  in  processor  B   are   NOT 

progressing  due  to  the  suspension  of  prccess  1  in 
processor  A. 


Processor  A : 

[ Pr  oce  ss  11 

V 
BkEaK (suspension) 

i 

i 

V 
PRDC_2.f  roro.l 


Processor  B : 

[Process  21 

V 

i 

V 
accept  f  rorr_l  (  ) 


! 
v 

PR0C_3.f  rom_2 


( s  wapped  out ) 


[Process  3  ] 

V   (deadlock) 
accept  f  rom_2 I ) 


Figure  5.1a:   Deadlock  in  a  multiple  processors  system 


*  It  is  not  a  temporary  blocking  of  all   processes 

because  if  the  breakpoint  is  not  resumeo  in  some  finite 

time  then  a  deadlock  will  be  detected  by  the  Concurrent 
C  system. 
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Similarly)  in  a  single-processor  environment 
(see  Figure  5.1b)  the  dead  I  ock  uill  also  arise  but 
it  will  take  a  longer  time.  This  is  so  because 
tnese  three  prccesses  are  utilizing  the  same 
processor.  Thus  the  deadlock  is  NOT  obvious  until 
sometime  later.  In  this  exairple,  the  deadlock 
will  not  occur  if  the  break  pointing  (suspension) 
of  process  1  will  also  cause  the  rest  of  the 
processes  (2  and  3)  to  stop  through  the  bottleneck 
approach  for  providing  suspension.  Howevert  the 
situation  will  get  worse  if  processes  can  be 
prioritized  because  it  complicates  the  analysis  of 
swapp  i  ng  , 
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S  ing  I e-pr  ocesso  r : 

[Process  1  ] 
i 

V >  swapped  out   [Process  2J 

i 
V 


swapped  out    < 


->  swapped  out 


>  [Process  31 

■ 

V 

[Process  2]  < —  swapped  out  <- 
■ 

V 

< swapped  out  < 

V 
[3RE  4K      >    swapped    out >    [Process    3! 

;  i 

.  V 

:  < swapped  out  < 

:  V 

:  accept  from  1  (...)  — >  swapped  out  — MProcess  3] 


accept  fr  om_2  (...) 
( dead  I och  )      ! 


PKDC_3  f  rGn._2  (...) 


Figure  5.1c:   DeadlocK  in  a  single  processor  system 


Though  these  three  basic  features  (namely, 
(i)  overall  vie*  approach  of  processes  during 
debugging,  (ii)  the  selected  process  states  and 
(iii)  suspension  of  all  processes  during  a 
breakpoint  uy  a  process,  are  quite  simple)  they 
are  language  dependent.  The  next  section 
describes  tr.e  implementation  of  these  features  in 
a   trace  facility  or  rudimentary  debugging  package 
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for    Concurrent    C  . 

5.5:     Iffljjlsififitatian  ai  Easia  dsEuaaiaa  iealuiss 

To  be  able  to  visualize  the  overall  states  ot 
a  concurrent  program  in  terms  of  the  individual 
component  processes)  a  kina  of  icon  is  employed 
to  represent  each  process  and  its  state.  This 
implementation  decision  was  made  in  order  to  allow 
all  processes  to  be  presented  on  the  CRT  screen 
simultaneously.  Since  Concurrent  C  is  an 
enhancement  of  Ci  it  can  invoke  any  of  the  C 
library  routines  dna  packages  [GEhAMI  L  ROCME  84J. 
To  implement  the  process  "icons"?  a  screen 
package  [ARNOLD  83]  available  or  UNIX  system  is 
employee.  Each  process  can  be  represented  by  a 
rectangular  box  and  each  box  possesses  three 
pieces  of  information:  process  name>  process  type 
and  status  istate). 

A  process  name  is  composed  of  a  number  which 
represents  the  position  of  a  process  in  the 
sequence  of  processes  that  have  been  createo  in  a 
program  ana  the  process  variable  name  associatea 
with  that  process.  For  instance?  '1:  b_ngr'  in 
Figurt   5.2   means   this   process   is   the   second 
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process  created  within  this  concurrent  program  and 
the  process  variaDle  narre  associated  with  this 
process  is  o_mgr . 

A  process  type  is  one  of  the  process  types 
defined  within  a  concurrent  program.  In  this 
case?  the  word  "manager"  en  the  second  line  in 
Figure  S.2  represents  the  type  of  process, 
"manager",  declared  for  this  particular  process 
b_myr . 


The  status  component  represents  a  process 
state  and  any  relevant  information  related  to  that 
state.  For  example,  the  last  line  of  Figure  5.2 
means  this  process  is  about  to  execute  a  'select' 
clause.  In  this  case,  the  word  'before'  is  a 
relevant  piece  of  information  related  to  the  state 
S  ('Select').  Anotner  example  of  relevant 
information  relateo  to  a  state  such  as 
'communicating'  will  be  the  name  of  a  transaction 
call  and  whether  the  state  is  before  or  after  the 
transaction  call. 
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!  1 :  D_iT.gr 
{manager 

IS:  before 


Figure  5.2:  A  representation  of  a  process  by  an  "icon" 


5.5.1:  ______  of.  _  _RT  screen  _n  representing  _ 

£______£G_  £  ___3_2_ 


Unfortunately!  due  to  the  size  of  a  terminal 
screen  (<!4  x  80  characters)!  tne  maximum  number 
of  boxes  that  can  be  aisplayed  at  any  one  time  is 
ONLY  eighteen.  However!  whenever  a  process  has 
terminated)  its  box  is  salvageo  for  later  use  by 
another  process  if  there  is  one. 


As  a  common  practice!  a  programmer  should 
always  start  off  with  a  small  number  of  processes 
and  increase  the  number  once  it  is  certain  that 
they  work  in  a  small  number.  By  the  time  one  gets 
to  a  large  number  oi  processes)  normally  further 
debugging  is  not  neeuea  as  errors  have  been 
discoverer]  while  executing  a  small  number  of 
processes.  This  argument  is  only  valid  if  the 
small  number  of  processes  are  independent  of  each 
other  (i.e.!  there  is  no  interaction  between  any 
of  them)  anc  the  environment  where  these  processes 


are  running  has  no  limitation  on  the  number  of 
existing  processes  at  any  one  time.  However) 
many  versions  of  UNIX  enforce  a  limit  on  the 
number  of  processes  that  one  user  can  run  at  a 
time!  typically  this  limit  is  set  to  about  20 
processes  [GEHAN1  E  KOOfE  8*].  Tnus,  the 
limitation  of  eighteen  boxes  should  not  hinder  any 
concurrent  programmer.  Furthermore)  if  a 
programmer  neeus  more  than  eighteen  boxes)  the 
rest  of  the  processes'  information  are 
automatically  cisplayed  in  the  message  area  on  the 
same  screen  i.e.(  line  sixteen  to  twenty-one  of  a 
screen  instead  of  an  'icon'  and  these  six  lines 
are  scrollable. 


5.5.2:   iiamaaciaiih  st  c.p.£c.u.r.i§n.i  £  ijiD^EH  Bacasst 
turn  lbs  ioicisuiEDlsfl  asiiuaaioa  isiiuiss 


In  contrast  w i tn  the  Concurrent  C  Window 
Manager  [THOMAS  84])  which  allows  only  uo  to  eight 
processes'  states  to  be  displayed  at  any  one 
instance)  this  implementation  allows  up  to 
eighteen.  hith  tne  Winoow  Manager)  output  from 
the  process(es)  is  displayed  on  the  four 
rectangular  boxes  assigned  to  four  selected 
processes.  On  the  other  hand)  the  author's 
implementation   allocs    all    output    from    the 
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processles)   to  De  displayed  on  the  bottom  section 

of   a   CRT   screen.    However,  there   are   eight 

process  states  employed  by  the  Concurrent  C  window 

Manager  whereas  there  are  only  four   main   process 

states    and   many   substates  supported   in   this 

implementation  (refer  to  Table  1). 


Aobreviation 

P: 

S :  before 

S  :  after 

D:  before 

D  :  after 

A  :  -  x  X  >  :■'  >  x 

R: 
TP: 

bCi xxxxxx 

aC  :  xxx xx x 

tT: 


I',  e  a  n  i  n  g 

Process  is  created  ana  running. 

Before  'select'  statement. 

After  'select'  statement  (impossible 
if  'terminate'  is  an  alternative). 

Before  delay  statement  (impossible 
if  'delay'  is  an  alternative). 

After  delay  statement. 

Immediately  after  an  'accept'  statement 
with  the  first  seven  characters  of  a 
transaction  name,   xxxxxxx. 

Before  a  'treturn'  statement  in  an  'accept'. 

Before  a  transaction  pointer  statement 
is  used  for  a  call. 

Before  a  transaction  call  with  the  first  six 
characters  of  a  transaction  name,   xxxxxx. 

After  a  transaction  call  with  the  first  six 
characters  of  a  transaction  name,   xxxxxx. 

Before  a  timed  transaction  call. 

Table  1:  Substates 


unfortunately,    the   Concurrent 
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Manager  aoes  not  allow  any  stepping  except  by 
using  the  Control-s  keystrokes  for  the  inaccurate 
and  temporary  suspension  ot  a  concurrent  program. 
This  implementation,  however,  does  support 
stepping  but  only  at  output  statements  to  a  CRT 
screen  ana  at  every  change  ot  any  process  state. 
It  automatically  breakpoints  at  every  output  line 
and  at  any  change  in  any  of  the  processes'  state. 
Moreover,  a  user  has  the  ability  to  skip  as  many 
breakpoints  as  he/she  likes  by  specifying  a  number 
as  prompted  for  after  each  breakpoint  is  executed. 
The  prompt  is  displayed  on  line  twenty-three  of  a 
screen.  Refer  to  the  following  table  (Table  2) 
for  other  comparisons  between  Concurrent  C  Window 
Manager  and  the  author's  implementation. 
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Concurrent  C  window  Manager 

1.  Uses  screen-package. 

2.  Invoked  by  manual 
insertion. 


The  author's  implementation: 

1.       Uses    screen-package. 

2  •   I  nvoked  through 
a  preprocessor. 


3.  E  i  gnt  processes  are 
visible. 

4.  Process'  output  to 
a  CRT  sc  r een  i  s 
displayed  in  one 
of  the  four 

r ec tangu lar  boxes. 

5.  Free  up  the  process 
box  when  a  process 
is  t e  rm  i  na ted  . 

6.  Freedom  of  switching 
process  '  out  put  to  a 
CRT  screen  be  cisplayed 
on  the  tour  rectangular 
boxes . 


3.  Eighteen  processes 
are  visible. 

4.  Process*  output  to  a  CRT 
screen  is  displayed 

at  the  lower  portion 
of  a  CRT  screen . 


5.   Free  up  the  icon  when  a 
process  is  terminated. 


6.   All  output  to  a  CRT 

screen  are  displayed  on 
the  iower  portion  of  a 
CRT  screen . 


7.   Eight  distinct  states, 


7.   Four  distinct  states  and 
many  subs  t  ate  s  . 


Br  eak  by  Contr  o I -s. 


8.   Break  by  Control-s  or  at 
each  screen  output 
statement  and  at  every 
change  of  any  process 
s  tate  . 


9.   So  "single"  stepping, 


10.  Capable  of  refreshing 

a  CRT. 

11.  Can  be  aborted  by  a 
Con  t ro  I  -C  . 


10. 


Single  stepping  at  screen 
output  s  t  atemen  t . 

Unable  to  refresh  a  CRT. 


11.   Can  be  aborted  by 
a  Con  t r o  I  -C  . 


Table  2:   Comparison  of  Concurrent  C  Window  Manager  and 
the  author's  implementation 


5.5.3:  lffiulSOiSIJisiiaD  fll  SlalfiS  lL3D5ili2Q 

In  order  for  the  tracing  facility  to   present 
the   state   of   each  process  to  a  programmer,   the 
tracing  facility  has  to  know   the   state   of   each 
process  at  any  instance.   This  can  tie  ac  coirp  I  i  s  he  d 
by  updating  the  respective   box   of   each   process 
whenever    a    process    changes   its   state.    As 
mentioned  earlier   in   section   5. 4.2. 3,    we   are 
interested     ONLY     in    states    like    active, 
communicate,   delayed,  ana  terminated.   To   enable 
a   tracing   facility  to  reflect  these  states,   the 
source  code  of  a   concurrent   program   has   to   be 
modified   to   include   some  updating  statements  at 
the  appropriate  places  where   a   state   transition 
takes  place.   Such  places  include  tne  beginning  of 
a   process,     communication    statements    (viz., 
transaction   call  and  'accept'  statements),   delay 
statements      and       terminate       statements, 
respectively. 

The  first  three  states  can  Oe  done  easily, 
but  the  last  state,  "terminated",  is  very  hard. 
A  process  in  Concurrent  C  can  terminate  whenever 
it  reaches  the  end  of  a  process  body  or  executes  a 
"terminate"  statement  within   a   'select'   clause. 
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The  hardest  parti  or  an  impossible  one*  is  when 
it  executes  a  "terminate"  statement.  This  is  Cue 
to  the  implementation  of  Concurrent  C  in  which  the 
"terminate"  statenent  is  required  to  be  all  by 
itself  textually>  i.e.)  it  CAI\NCT  be  preceded  by 
any  other  statement  except  "or">  and  consequently 
whatever  statements  follow  it  are  ignored.  Thusi 
there  is  no  way  tc  insert  any  update  statement  to 
reflect  whether  a  "terminate"  statement  will  be  or 
has  been  executed.  If  this  approach  is  desired? 
the  only  way  cut  is  to  modify  the  Concurrent  C 
compiler.  Nevertheless.  the  terminated  state  can 
be  representee  by  wiping  out  the  icon  representing 
a  process  which  has  terninated.  To  detect  whether 
a  process  has  terminated)  a  Concurrent  C  Pui  It-in 
routine  called  c_active  can  be  invoked  [GEHANI  i. 
ROUilE  8<i). 


Last  but  not  least)  the  implementation  of 
suspending  prccesses  whenever  a  process  is 
breakpointed  can  oe  achieveo  by  queueing  up  all 
processes'  requests  to  update  their  respective  box 
in  a  process.  This  is  essentially  a  bottleneck 
approach.  This  is  auite  easily  accomplished)  but 
is  not  the  most  efficient  approach.  For  example) 
the   scenario   aepicted   in   figure  5.1b  can  never 
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result  in  a  deadlock.  This  is  because  the 
breakpoint  request  will  have  to  request  an  access 
to  the  bottleneck  process  before  the  breakpoint  is 
granted  anc  the  rest  of  the  processes  must  also 
request  an  access  to  the  bottleneck  process  before 
an  update  of  a  process  state  can  take  place.  Thus 
all  incoming  requests  will  be  queued  and  sc  all 
the  involved  processes  will  be  suspended. 


For  this  implementation)  a  fronteno 
debugging  process  is  automatically  Inserted  into 
each  concurrent  program.  This  debugger  prccess  is 
tne  bottleneck  process  we  have  been  talking 
about.  It  handles  the  update  request  anc  any 
other  debugging  request  subnitted  by  a  programmer. 
This  approach  will  still  preserve  the  semantics  of 
a  concurrent  program  even  with  the  debugging 
process  included.  1 n i s  is  because  every  process 
has  to  go  througn  tnat  debugging  process  to 
perform  state  update.  screen  10  and  breakpoint. 
So  every  process  will  oe  affecteo  in  one  way  or 
another  about  tne  same  amount.  Doviously>  the 
overall  behavior  of  the  concurrent  program  will 
appear  slower  and  it  will  consume  more  cpu  time 
when  the  bottleneck  process  is  introduced. 
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5.  5.  4:  lj££L  iQl££iase 

The  tracing  facility  is  implemented  as  a 
preprocessor  which  parses  the  source  text  of  a 
Concurrent  C  program.  During  the  parsing*  it 
writes  to  an  output  file  the  parsed  source  text. 
Furthermore.  whenever  a  state  transition 
statement  (such  as  transaction  callj  "accept") 
"delay".  "select".  etc.)  is  parsed,  some 
screen  update  statements  are  appended  to  the 
output  file.  Consequently,  a  user's  source 
program  is  not  modified  but  a  copy  of  the  original 
program  with  added  screen  update  statements  is 
generated.  The  detailed  instructions  of  how  to 
use  tne  tracing  facility  are  illustrated  in  the 
Appendix  -  User's  Manual. 

5.6:  IQe.  L2.1S.    of.  a.  saamilSI  in  Du.iidiD.2  a.  deoyaaef. 

As  we  Know.  the  purpose  of  a  compiler  is  to 
translate  a  programming  language  (source  language) 
to  executable  codes  (the  object  or  target 
language)  lArfO  (.  ULlMAN  79].  With  the  existence 
of  a  compiler.  we  do  not  have  to  worry  about  the 
idiosyncrasies  of  register  usage  and  assembly 
instructions;     let    alone    about    customizing 
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assembly    language    interface    routines.    Some 
interface  routines  are  needed  to   allow   a   user's 
prosram(s)   to   interact  with  the  operating  system 
for  utilizing  services  not  supported  by  the   high- 
level   language  in  whicn  a  user  writes  prograir(s). 
However,   if  the  source   code   of   a   compiler   is 
available,    then   we   can  ennance  the  compiler  by 
implementing  some  features  which  are  important  for 
a   debugger   [YtllilsG   811.    Features  like  symbolic 
debugging  use  an  elaborate   symbol   table   whereas 
source   level   debugging  uses  line  number  ano  code 
mapping.   Since  a  compiler  can  parse  a  program   in 
sequence  of  lines  and  generate  a  symbol  table,   we 
need  only  to  ace  some  more  cooe  to  the  compi  ler  to 
accomplisn   the   two   features  (symbolic  aeDugging 
and   source   level   debugging)    just    mentioned. 
Furthermore,   we  can  understand  how  the  program  is 
organized   at   memory   level    oy    studying    the 
executable   coces   whicn   are   generated   after   a 
successful    compilation.     By    analyzing     the 
executable   codes,    we   will   be  able  to  know  how 
much   space   (memory)   is    allocated    for    each 
variable,    for   example.    Moreover,    we  will  be 
able   to   know   how    tne    variables    are    kept 
(addressing!,    and   the   convention   on  using  the 
registers,    etc.     Only    with    such    Detailed 
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knowledge   cf  trie  conpl  ien   can  a  modification  be 
carried  out  to  include  some  debugging  features. 


Unfortunately!  the  source  code  for 
Concurrent  C's  compiler  is  NOT  available  to  Kansas 
State  University  at  tnis  time.  Thus*  it  is  very 
haru  to  incorporate  a  deougger  to  Concurrent  C» 
unless  one  desires  to  re-invent  the  wheel  for 
Concurrent  C  by  writing  a  new  compiler.  However, 
one  can  still  look  at  how  the  compiler  of 
Concurrent  C  generates  assembly  code  to  configure 
a  concurrent  program  by  examining  the  assembly 
output  of  the  compiled  program  (with  a  -S  option). 
Once  we  know  how  they  are  configured)  we  still 
CANNOT  insert  any  code  into  the  compiler  to 
generate  the  necessary  adoitional  code  required  to 
facilitate  the  implementation  of  a  debugger.  But 
there  is  a  solution  to  this>  i.e.)  we  could 
parse  the  assembly  output  and  insert  into  that; 
unfortunately  the  chances  of  making  mistakes  are 
very  great  and  cost  too  much  time. 

Consequently)  the  intention  of  building  a 
debugger  for  Concurrent  C  has  been  discouraged. 
However>  to  get  a  teel  of  now  hard  it  is  to  build 
a  debugger)   a  tracer  has  been  implemented  instead 
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which  incorporates  the  basic  features  described  In 
section  5.4.  The  differences  between  a  tracer  anc 
a  debugger  will  be  discussed  in  the  next  section. 

5.7:  l£S£££  vSLilii  fl£D.ug.S,e.£ 

A  tracer  is  essentially  a  highlighter  which 
reports  the  necessary  information  a  programmer 
neecs  in  order  to  determine  the  behavior  of  a 
program  undergoing  execution.  But  a  debugger  is  a 
powerful  tool  tnat  allows  a  programmer  to  probe 
the  program  he/she  is  running.  It  has  more 
capabilities  than  a  tracer.  It  allows  a 
programmer  to  manipulate  the  state  of  a  program, 
set  breakpoints  to  skip  irrelevant  information, 
etc.  Essentially,  a  debugger  is  a  friendlier 
tool  to  use  than  a  tracer  Because  a  debugger 
presents  ONLY  information  requested  by  a 
programmer.  Since  a  tracer  can  assist  a 
programmer  in  nailing  down  a  malignant  prccess, 
it  can  be  used  as  a  first  step  in  the  act  of 
debugging  a  program. 
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Chapter  o 
Future  research  and  conclusion 


After  an  introduction  to  concurrent 
programming  and  a  presentation  of  approaches  to 
debugging  Concurrent  C  programs)  it  is  now  time 
to  comment  on  the  applications  of  the  implemented 
tracing  facility  and  to  comment  on  future  research 
in  Concurrent  C  debugging. 

6.1:  AEEii;jiion  0.1  tne  ira.c.ine3  lasiiii* 


Since  there  is  no  debugger  tor  Concurrent  C 
anc  the  Concurrent  C  Window  farager  is  hard  to 
use)  tne  Implemented  tracing  facility  is  intended 
to  assist  a  novice  or  experienced  Concurrent  C 
programmer  to  overcome  the  frustration  of 
debugging  a  Concurrent  C  program.  With  the 
"over  a  I  I  -v  i  en"  approach  of  presenting  each  and 
every  process  state  of  a  Concurrent  C  program  on  a 
CkT)  this  approach  will  greatly  help  a  programmer 
in  identifying  tne  two  notorious  errors  in 
concurrent  programming  viz.»  deadlock  and 
unwanted  race  condition.  Furthermore,  with  the 
ability  to  breakpoint  at  every  output  statement 
and  at  every  cnanye  of  a  process1  state  within  a 
Concurrent  C  program.   a  user   can   trace   through 


his/her  Concurrent  C  program  at  his/her  own  pace. 
Moreover,  a  user  has  the  ability  to  skip  as  many 
breakpoints  as  ne/slie  likes  by  specifying  a  number 
in  response  to  a  prompt  after  each  breakpoint  is 
executed.  The  total  number  of  Breakpoints  is 
displayed  whenever  a  Breakpoint  is  executed.  Thus 
a  user  can  save  some  time  and  some  keystrokes  to 
arrive  at  a  state  where  he/she  suspects  a 
Concurrent  C  program  is  going  tc  misbehave  or 
crash. 

6.21  Future  Research  j.n  Corcurrent  £  fiep.ug.2ing 


Since  the  source  code  of  Concurrent  C 
coirpiler  is  not  available,  a  debugger  for 
Concurrent  C  has  not  been  implemented.  Instead, 
a  tracing  facility  tor  Concurrent  C  nas  been 
implemented.  In  the  future,  if  the  source  code 
is  available  then  the  tracing  facility  can  be 
extenoeo  to  provioe  all  of  the  capabilities 
required  by  a  debugger.  Inasmuch  as  the  tracing 
facility  is  incorporated  into  a  Concurrent  C 
program  by  passing  that  program  through  a  parser 
to  insert  necessary  screen  package  routines  ano 
some  tracing  processes,  some  portions  of  this 
parser's  cooc  can  be  adoed  to  the  compiler  so  that 
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insertions  can  De  done  while  con-piling  a 
Concurrent  C  program.  Thus>  the  work  aone  on  the 
tracing  facility  can  De  reused. 

besioes  implementing  the  presented 
approaches!  one  might  wart  to  pursue  the  idea  of 
how  a  datatase  model  of  deougging  would  be 
beneficial  to  Concurrent  C  programs.  At  this 
moment?  a  cataoase  model  of  debugging  seems  very 
promising  because  instantiation  of  process  types 
can  be  handled  elegantly  with  relational  database 
model.  This  way  of  handling  is  cue  to  tne  fact 
tnat  each  prccess  type  is  just  a  cistinct  database 
file  in  wnich  each  record  represents  an  instance 
of  the  process  type  and  each  record  is  keyed  by 
the  process  iaentif  ication*  which  has  been 
defined  in  Concurrent  C.  The  fields  in  each 
record  of  the  process  type  can  be  the  variables 
local  to  the  process*  actual  parameters  involved? 
etc.  The  only  other  problem  is  how  to  set  up  the 
relationship  to  represent  tne  possible  interaction 
between  oilferent  processes.  One  possible  way> 
perhaps?  is  to  setup  relationships  based  on  the 
access  rights  of  each  process  type  with  regard  to 
other  processes.  The  rest  of  the  relationships 
wouM   be   just   the   same   as   these  presented  in 
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Chapter  4  for  OMEGA  system  except  for  a  few 
relationships  caused  t>y  concurrency  constructs 
like  "accept",  "terminate"*  "select",  "uelay", 
etc.  Thus,  it  will  be  interesting  to  see  how 
these  relationships  work  together  to  represent  the 
semantics  of  a  Concurrent  C  program  and  how  easily 
the  program  can  be  aebuyged. 

With  more  advanced  technology  for  graphical 
tools  avai  lable  In  the  near  future,  graphical 
supports  for  deOLyging  will  be  widely  employed. 
This  is  because  tne  cost  of  such  supports  will  be 
greatly  reduced  and  will  stimulate  more  research 
in  that  avenue.  If  such  breakthrough  is  achieved 
then  "paperless  programming"  and  graphical 
interface  will  oe  highly  appreciated  by  users. 
Research  in  user  interfaces  using  graphics  ir.ay  be 
cf  great  interest  oecause  it  is  hard  to  create  an 
interface  that  can  easily  be  used  without  much 
confusion  and  irucn  learning  and  at  the  same  time 
sel  f-exp  laratory. 


Another  future  area  of  research  is  concerned 
witn  the  possibility  of  a  knowledge-based  model  of 
debugging  for  Concurrent  C  programs.   As  stated  in 
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Chapter  <*,         the  hardest  part  is  to  represent  the 

kno.  ledge  ol  the  interaction  between  the  processes 

in    a    Concurrent    C   program.    Cnce   tnat   is 

accomplished  then  debugging  a  Cor.current  C  program 

will   be  very  easy  as  localization  of  error  can  be 

automated.   To   accomplisn   this   automated   task) 

tne   debugger  must  have  a  knowledge  of  the  goal  of 

the   concurrent   program.    The   tough    part    is 

determining   how   to   represent   the   goal   to  the 

debugger.   As  a  stepping  stone*   one  can  allow  the 

debugger   to  checu  whether  a  process  is  performing 

the   correct   task   tnat    was    intended    by    a 

programmer.   This  can  te  accomplished  by  supplying 

the  specifications  of  a  process   and   letting   the 

system    verify    that    the   process   behaves   in 

accordance    with     its     specification.      Any 

discrepancy   encountered   during  this  verification 

will   be   reported.    The   specifications    should 

incluae   with   which   prccessles)  a      process  will 

communicate  ana  what  it   will   communicate.    This 

Information   is   needed   just  to  verify  the  access 

right  between  processes.   Once  these  processes  are 

verified,    the   debugger   should  then  verify  that 

the  goal  of  this  concurrent  program  is   met   i.e., 

the  net  effect  cue  to  its  processes  interaction. 
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6.3:  £2Li£lUiiaQ 

Constructing  a  debugger  for  concurrent 
programs  is  irore  difficult  than  for  sequential 
programs.  The  difficulties  arise  because 
concurrent  programs  are  composed  of  multiple 
sequential  programs  and  these  sequential  programs 
can  interact  with  each  other.  As  £  result, 
additional  mechanisms  (other  than  the  ones  found 
in  sequential  program  debuggers)  are  needed  to 
construct  a  debugger  for  concurrent  programs. 

One  of  the  additional  mechanisms  is  the 
"overall-view"  capability.  with  this  capability) 
trie  state  of  each  and  every  process  is  visible  at 
any  instance.  This  mechanism  is  neeoed  to  solve 
the  two  most  common  errors  which  occur  in 
concurrent  programming  viz.,  deadlock  and  unwanted 
race  condition.  with  this  mechanism,  a  user  can 
identify  the  two  notorious  problems  quickly. 
Another  required  mechanism  is  the  capability  to 
suspend  all  existing  processes  in  a  concurrent 
program  if  one  ot  them  executes  a  breakpoint. 
Tnis  suspension  mechanism  is  the  most  crucial  one 
in  concurrent  programming  because  a  timing 
violation    by   other   processes   is   possiDle   if 
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suspensi 


on  of  other  processes  is  not  enforced. 


^ith  these  two  features  supplementing  the 
mechanisms  from  a  seauential  debugger)  a  powerful 
concurrent  debugger  can  be  constructed. 
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Appendix  -  USER  'S  KANUAL 

This  tracing  facility  is  intencecl  to  assist 
Concurrent  C  programmers  to  debug  their  Corcur rent 
C  programs.  It  enables  a  Lser  to  visualize  the 
overall  states  of  a  Concurrent  C  program  in  terms 
of  tne  individual  component  processes.  Each 
process  anc  its  state  are  represented  by  an  icon. 
This  implementation  decision  was  made  in  order  to 
allow  all  processes  to  be  presented  on  the  CRT 
screen  simultaneously.  Since  Concurrent  C  is  an 
enhancement  of  Ci  it  can  invoke  any  of  the  C 
library  routines  and  packages  tGEHANI  £.  ROOKE  8<<]. 
To  implement  the  process  "icons"i  a  screen 
package  [ARNOLD  83)  available  on  UNIX  system  is 
employed.  Each  process  can  De  represented  by  a 
rectangular  box  and  each  box  possesses  three 
pieces  of  information:  process  name>  process  type 
and  status  I  state  ) . 

A  process  name  is  composed  of  a  number  which 
represents  the  position  of  a  process  in  the 
sequence  of  processes  that  have  been  created  in  a 
program  anc  the  process  variable  name  associated 
with  that  process.  For  instance?  '  1 !  b  _  m  g  r  '  in 
Figure   1  means  this  process  is  the  second  process 
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created  within  this  concurrent  program  and  the 
process  variable  name  associated  with  this  process 
i  s  b_mg  r . 


! 1 : D_mg  r 
! manage  r 
! S :  De  f  or e 


Figure  l:  A  representation  of  a  process  by  an  "icon' 

A  process  type  is  one  of  the  process  types 
defined  within  a  concurrent  program.  In  this 
casei  the  word  "manager"  on  the  second  line  in 
Figure  1  represents  the  type  of  process, 
"manager",  declared  for  this  particular  process 
b_mg  r  . 

The  status  cornponert  represents  a  process 
state  and  any  relevant  information  related  to  that 
state.  For  example,  trie  last  line  of  Figure  1 
means  this  process  is  about  to  execute  a  'select' 
clause.  In  this  case,  the  word  'before'  is  a 
relevant  piece  of  information  related  to  the  state 
S  (  'Select'  ). 


The  details  of  all  the  iwplementated   process 
states  for  this  facility  are  depicted  in  Taple  1. 
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Abbr  ev  i  at  I  on 

P: 

S  :  before 

5 :  after 

D  :  before 

D:  after 
A : *  x  xxxx  x 

R: 
TP: 

bC : xxxxxx 

aCi xxxxxx 

tf: 


Kean  i  n g 

Process  is  created  ana  running. 

Before  'select'  statement. 

After  'select'  statement  (impossible 
if  'terminate'  is  an  a  I  ter ra t i ve ) . 

3efcre  delay  statement  (impossible 
if  'oelay'  is  an  alternative). 

After  delay  statement. 

Immediately  after  an  'accept'  statement 
with  the  first  seven  characters  of  a 
transaction  name.   xxxxxxx. 

Before  a  'treturn'  statement  in  an  'accept'. 

Before  a  transaction  pointer  statement 
is  used  for  a  call. 

Before  u  transaction  call  with  the  first  six 
characters  of  a  transaction  narret   xxxxxx. 

After  a  transaction  call  with  the  first  six 
characters  of  a  transaction  ramei   xxxxxx. 

Before  a  timea  transaction  call. 

Tab  I  e  1  :  Subs ta  te  s 


Unfortunately.   due  to  the  size  of  a  terminal 
screen   ( 2  *   x  oO  characters).   the  maximum  number 
of  boxes  that  can  be  displayed  at  any  one  time   is 
ONLY  eighteen. 
l£  y££  it!£  iaciiit^,   the  ioiicw|ng.  step_s  £y;S.T   b.£ 


je  sure  ihot  your   Concurrent   C   program 
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does  not  have  any  compilation  error,   but  warnings 
are  tolerable. 

2.  To  enable  the  tracing  capability  be 
included  in  your  Concurrent  C  program,  you  have 
to  invoke  a  preprocessor.  To  invoke  the 
preprocessor,   use  the  following  command: 

/usrb/chua/oeta/TPP  filename 

where  'filename'  is  tne  file  name  of  your 
Concurrent  C  program  (BE  SURE  that  it  has 
the  '.cc'  extension). 


3.  The  preprocessor  will  produce  two  files 
called  'filenameT'  and  '  f  i I enameTRACE ' . 
'FilenameT'  is  actually  the  name  of  your 
Concurrent  C  program  with  a  'T'  inserted  just 
before  the  '.cc'  extension  whereas  '  f i  I  enameTRACE ' 
is  a  fi  le  n3ii.e  of  your  Concurrent  C  appended  with 
the  woro  'TkACE'.  For  example  the  name  of  your 
Concurrent  C  program  is  'test.cc'  then  the  file 
name  for  ' f i I enameT '  is  'testT.cc'  and  the  file 
name  fcr  '  f i lenameTRACE '  is  '  tes t .  ccTRACE ' . 

'FilenameT'  is  a  file  which   has   tne   tracing 
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Information  annotated  into  your  original 
Concurrent  C  program.  Cn  the  other  h  a  n  d  » 
'  f  i  I  enaineTRACE  '  may  contain  an  error  message  which 
is  resulted  from  an  error  encountered  during  the 
conversion  and  halted  the  conversion.  This  error 
message  always  specifies  which  line  of  your 
Concurrent  C  program  that  the  error  was  detected. 
This  error  arises  because  the  Concurrent  C 
compiler  is  very  liDeral  on  syntax  checking, 
Howeveri  a  report  aoout  the  number  cf  static 
processes  within  this  Concurrent  C  program  is 
always  included  in  the  'filenarreTRACE.' 

4  .  If  there  is  an  error  message  reported  in 
the  '  f  i  I enameTRACt '  then  the  output  file, 
'  f  i  I  enaineT '  i  is  incomplete!  Thus  you  have  to 
correct  the  proolem  to  eliminate  the  error.  It 
you  think  tne  problem  is  in  the  preprocessor) 
report  the  error  to  the  personnel  in-chargea. 


5.  If  there  is  no  error  at  all  ir  the 
'  t  i  I enameTRACE '  then  you  may  now  proceed  to 
compile  the  outputted  file,  ' f i  I e name T ' .  To 
compile  '  f  i  I  enaineT' <   type  the  following  command: 
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/usrb/chua/beta /COM PILE   ' f  i  lenameT  ' 

INote!   Do  not  include  tne  single  quote   in 
the  command) 

6.  If  there  is  any  compilation  error,  try 
to  fix  it  yourself.  Please  IGNORE  any  compilation 
warning  especially  "warning:  g_temp_pia  not 
used.  " 

7,  It  the  compilation  was  successful  then  an 
object  file,   'a. out',   would  have  been  produced. 

6.  To  rar  the  object  file,  just  type  the 
object  file  narre,   'a. out'. 


9.  Jurinc  tne  execution  of  your  object  file, 
a  suspension  will  L;  e  taken  whenever  an  output  to 
the  CRT  or  a  change  in  any  one  of  the  processes' 
state  is  exeucted.  During  this  suspension,  a 
prompt  for  a  number  to  represent  how  many  output 
statements  to  the  CR1  and  how  many  changes  of 
process'  state  before  the  next  suspension  is  to  be 
taken,    will   be  prompted.   Furtheuore,   a  number 
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representing  the  number  of  output  statements  and 
tne  numDer  of  changes  in  processes'  states 
executed  so  far  is  displayed.  If  you  respond  with 
a  '-999'  then  the  program  will  be  executed  to 
completion  or  to  wnerever  it  cannot  proceed. 
Houeveri  if  you  respond  with  a  positive  number 
tnen  the  next  suspension  will  not  occur  until  the 
sum  of  the  number  of  output  statements  and  the 
total  number  of  processes'  state  changes  equal  to 
that  number  you  submitted.  Any  other  respond  will 
be  treated  as  a  positive  one. 

10.  If  your   object   file   does   not   run   to 
completion  with  tne  below  message  displayed) 
i<4«««««   NORMAL  TERMINATION'   ♦**#♦*" 

you  have  to  reset  your  terminal  by  typing   the 
c  o  m  m  a  n  d  J 

1  / us rb/chua/ beta /UNDO CRT' 

before  any   other   commands!    otnerwise   your 
terminal  will  behave  strangely! 

!J5£L  ££iiLi£ii£Ui 
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a)  User's  "include"  files  CANNCT  De  included  in  a 
user's  Concurrent  C  progratr. 

b)  All  transaction  calls  issued  by  global 
processes  co  not  have  any  tracing  information 
annotated  with  them  in  order  to  ciscourage  usage 
of  global  processes. 

c)  Timed  transaction  calls  may  not  work  very  well 
because  irost  of  them  will  be  expired  before 
rendezvous  csn  occur  as  processes  will  oe  slow 
down  by  any  "breakpoint." 

d)  If  a  user's  crogram  is  too  large  (i.e.)  about 
3b  Kbytes  of  compiled  code))  compilation  error  is 
very  likely  with  the  error  message  "internal 
/usr / I  oca  1/  I  i b/ccpp  error:  input  buffer  overflow." 

e)  Use  the  built-in  constants  null_pidj  for 
null  process  ic  instead  of  the  value  zero. 

f)  Du  NOT  use  a  "soefine"  to  define  any  reservec 
symbols  (like  "{"»  ">" i  etc)  or  words  (like 
'select')   'accept')   etc). 

g)  DO  NOT  use  a  "typedef"  to  define  any  process 
types  but  a  "typedef"  may  oe  used  to  define  any 
types  of  transaction  pointers. 
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h)  All  screen  I/O  statements  (like  "printf", 
"scant",  etc)  must  be  in  a  process  Bocy  and  NOT 
in  a  function. 
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The  differences  between  sequential  and 
concurrent  programs  are  identified.  These 
differences  dictate  how  the  design  ol  a  debugger 
for  concurrent  programs  must  differ  from  a 
sequential  debugger.  Different  techniques  to 
facilitate  debugging  of  concurrent  programs  are 
discussed.  The  implementation  of  a  tracing 
facility  for  Concurrent  C  programs  is  presented. 
This  implementation  enables  all  of  the  processes 
in  a  Concurrent  C  program  to  tie  presented  by  icons 
on  a  CRT  which  keeps  track  of  their  inoividual 
process  state.  Furthermore,  the  ability  to 
breakpoint  a  process  and  at  tne  sarre  time  suspeno 
all  the  other  existing  processes  within  a 
Concurrent  C  program  is  implemented  in  this 
facility. 
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